Mobile ID SMS Bearer Latency in Some Mobile Network Technologies

The motivation of this blog post is to show an estimation of the time to complete a mobile ID transaction using SMS bearer in some mobile network technologies like 2G, 3G, and 4G.

The figure below describes the flow of a typical user authentication in the mobile ID service.

Figure 1: Example Mobile ID Transaction flow

When an Application Provider service requests user authentication from the MSSP (2), the MSSP sends a mobile signature request via a SMSC to the end user device (over the air, 3.) After signing, a SIM card creates a response and sends it back to the MSSP via the SMSC (4).

Considering that users are often impatient and cannot tolerate long wait times in between request and response flows (access request and access granted), the mobile ID service response time matters.

Mobile ID responsiveness is hugely influenced by:

  • Mobile network technology standard (4G, 3G, 2G)
  • Number of SMS (especially the length of the DTBS/DTBD).
  • Mobile network and service quality

The network technology standard specifies the latency and bandwidth of the network, which determines how fast an SMS message is delivered over the network. The latency of an SMS message in 2G is understandably higher than the latency in newer standards such as 3G or 4G.

The number of SMS is dependent on the cryptographic technology in use. On the Alauda P38 Lighting SIM card applet the number of request SMSs is 1, and number of response SMSs is 1 for 256 bit ECDSA signatures to 2 for 2kb RSA signatures.

Additionally, if the SMSC does a store-and-forward handling of the messages, it increases delivery latency both ways.

Other factors, which may influence responsiveness to a certain degree include:

  • Network signal strength
  • Mobile device attributes such as mobile OS etc.

The table below shows mobile ID performance figures in different mobile network technology standards, using 2K RSA. These figures have been measured in DNA network, Espoo, Finland, 2017.

Mobile Network Technology Round-trip time, seconds


4 – 7


6 – 9


14 – 20

Table 1: Estimated Mobile ID SMS Round-Trip Times (Finland)

Table 1 above and figure 2 below, show that the transaction time in the Kiuru MSSP platform is more or less negligible, with complete round-trip time (Signature request and responses) in the MSSP, only a fraction of a second (200 milliseconds). The bottleneck is the network latency. The round-trip time varies between 4 – 7 seconds in 4G, and 14 – 20 seconds in 2G.

Figure 2: Mobile ID transaction times (graph)

Below is the figure obtainable in Switzerland (Swisscom, Zürich, 2017) using the Swiss Mobile ID. Time measurements have been done with higher resolution ☺

Mobile Network Technology Round-trip time, seconds







Table 2: Mobile ID Communication Round-trip Times (Switzerland)

As shown in the above table, the importance of the mobile network standard in use cannot be over emphasized, with performance improvement of 11 seconds from 2G to 4G.

We understand that from the user’s perspective, user experience deteriorates quickly once it exceeds 20 seconds to authenticate to an AP’s service. And that is why we have worked to reduce the number of SMS messages to a minimum, such that the user wait time is as small as possible.

On the average, we estimate that the maximum wait time should not exceed 8 seconds in 2G, 5 seconds in 3G and 3 seconds using 4G network, irrespective of if 2K RSA or ECC is used.

Future of SMS Bearer

There are two future directions for SMS based communication:

  • SMS-over-IP [ETSI TS 124 341]
  • The 5G network

The SMS-over-IP offers as fast communication as the underlying network technology itself.

The 5G network offers extremely low latency. In 5G network our expectation is less than 2 seconds round-trip.

Posted in Blog

Methics to Launch Mobile ID Standard Solution at Mobile World Congress

Methics will, at the Mobile World Congress (MWC) 2017 in Barcelona, launch the Mobile ID Standard solution, a ready-made, complete and easy-to-deploy solution for Mobile Signature Services. MIDS combines Methics’ robust Kiuru MSSP platform with the well proven Alauda P38 applet for SIM cards.

The MIDS solution is designed to enable fast and simple deployment of mobile signature services by mobile network operators for managed digital authentication and identity services.

Please join us at the Finland Pavilion, located at 5F31 in Hall 5 for the launch on Monday, 27th February, 2017 at 16.00.

For more information, see the MWC press release.

Posted in News Tagged with: , , , ,

SHA-1 Hash Collision Demonstrated – At Predicted Cost Levels

The research result on October 2015 from Dutch CWI did estimate that actual finding of two messages that collide producing same hash value will be possible in cost in order of $100 000. See our previous: SHA-1 is no longer considered secure.

Fresh result from same team with sponsored computing cluster capacity demonstrates that this is indeed correct cost estimate.

Actual Impact of SHA-1 Hash Collisions

The actual impact has not changed in past year and half:

  • Rapid challenge/response processing is safe because finding a collision takes at least hours, probably weeks or months.
  • Long term signature non-repudiation security depends on the value of that signature — if spending $100 000 is low enough cost for somebody to replace whatever is behind given signature, then that long term signature is not safe if it involves SHA-1 hashes.

Previously the cost level of producing this kind of hash collisions has been at levels of so called State Actors. This sub-million cost level is in corporate / criminal organization ball park. Meaning that organizations wanting to do this kind of things have just become a lot more numerous.

When Will SHA-1 Follow MD5?

Both algorithms are built on similar Merkle-Damgård construction, like is also SHA-2 family.

MD5 timeline:

  • MD5 hash algorithm was published in 1992.
  • First public collision was demonstrated in 2004 taking 1 hour in a computer cluster.
  • Collision break in less than 1 second in 2013 with single PC.

SHA-1 timeline:

  • SHA-1 hash algorithm was published in 1995
  • First public collision was demonstrated in 2017 taking a bit over 1 year of time with around 100 device years executed during it.
  • Public collision demo taking 1 hour or less time in ____ ?
  • Collision break in less than 1 second in ____ ?


Posted in Blog

Meet us at MWC2017

Methics will be exhibiting the Kiuru MSSP solution for Mobile ID and Mobile Connect Services at the Mobile World Congress 2017. Meet us at the Finland Pavilion, stand 5F31 in Hall 5, where we will be exhibiting the solution.

Please reserve a meeting with us using our contact form, or emailing <>

Mobile World Congress is the world’s largest annual gathering of experts and industry executives in the mobile industry. The 2017 event will take place in Barcelona between 27 February to 2 March 2017.


Posted in News Tagged with: ,

Methics at AfricaCom 2016 – 15th to 17th November, 2016

africacom-smallThe AfricaCom is the largest and most influential Africa-focused tech event in the world – the meeting place for those driving Africa’s digital transformation. With the theme: “Economic Development and Social Empowerment through Digital Connectivity”, AfricaCom 2016, aims to elevate AfricaCom to become a powerful vehicle for digital transformation, economic development and social empowerment.

Methics will be exhibiting our Kiuru MSSP solution for Mobile ID and Mobile Connect Services at the event. Meet us at the TeamFinland stand E24, where we will be demostrating our solution and how it can help your company.

Posted in News

SIM-less authentication

The “SIM-less” in this context is a collection of all those techniques that do not use a SIM as a secure tamper proof hardware to implement the place for running the secure element function with a precisely known runtime environment.


Some technology vendors are claiming that they can do secure mobile authentication without a SIM.

That is fine, if they have found a way to create a security container that fullfills required Level of Assurance (LoA). Such is trivial for a very low LoA, but highest levels are harder to meet.

This is also easy to confuse with Common Criteria Evaluation Assurance Level (EAL).  They are somewhat different thing: LoA says about identity, and sets effectively but not explicitly a minimum EAL levels for implementation, plus adds additional requirements on how the registration is done.

To produce Level of Assurance 4 authentication everything must be tight: Registration method, Identity verification, the security module implementation must be hard (EAL3 or higher,) and finally the user interface must be unambiguous.

SIM-less Platforms

In addition to SIM card holding the trusted applications, recent developments have been around so called Trusted Execution Environment (TEE) specification by Global Platform.  Any other security environment requires that a general purpose platform (iOS, Android) is hardened against third parties accessing files and memory of the phone.

This general purpose protection does not happen in either Apple iOS, or in Android platforms.  Other platforms (Blueberry, Windows Phone) are in definite minority and less well known. [1, 2, 3, 4]  (Store files on Android internal filesystem, and they are somewhat protected. Store files on external memory card of Android, and they are open to everybody.)

In spring 2016 the FBI paid somebody a lot for a tool that can access recent iOS phone memory, and Apple does not know how it is done. Although Apple did find a suspicuous thing that was fixed in iOS 8.1 [5, 6]

Apple has done flash memory block erasing easy, but in earlier models nothing prevents physical access to device from replacing the flash device with another one in previous hardware generations [5].  Only most recent “A7” processor has an internal security enclave that is harder to access.

Keeping Secrets in Phone

Both Android and iPhone platforms have something called secure key storage API for PKI key material.

Latest high-end Androids document using TEE mechanism for this, but it is just API, and it can be implemented in many ways, not necessarily strongly secure. This API has a query method to find out if the key storage is strongly secure, but in case of cheapest model phones, the expectance value is that it will report “this is secure” while it isn’t.

The iPhones have similar mechanism, and given Apple’s attitude to security matters, it probably works correctly. (Subject to bugs. See iOS8.1 update above.)

If the Android or iPhone is “jail broken”, access to TEE mechanism can be compromised, and again neither the application nor the user can know for sure that the secret key data is truly unextractable.

Nevertheless we have seen several professionally security paranoid parties using Android as platform for a general population access token application:

  • Google Authenticator
  • Banks

In each case the application vendor is barely trusting their own thing, and nobody is trusting external vendor’s product.

How to do SIM-less Mobile Authenticator

In a few “easy” steps:

  1. Ensure platform trustworthiness
    • Let the platform to be audited and observed to be trustworthy
    • Let the end user to know in a trustworthy way of when the platform is in trusted mode
  2. Ensure the authenticator trustworthiness
    • Let the authenticator to be audited by third parties to be trustworthy

What kind of user interactions will it do?  The TEE UI specification defines specific graphical elements when a trusted application is in control, but anybody could do similar looking graphics.  Blueberry devices used to light up special (red?) LEDs when the secure mode was running.

Finally things like communication setup, possible encryptions and messaging start to be an issue but we stop here. If you have EAL3+ for secret keeping, the communication security becomes easier.

By the way: Even the SIM based security module authenticators fail in letting the user to know in secure way that they are interacting in secure mode.  The SIM-toolkit API implementations at phones are decently secure, but there are no special LEDs lighting up when that mode is interacting with keyboard and display. This is mostly due to historical evolution of the mobile phone systems.  Next evolution step is to have those special indication LEDs.






Posted in Blog

Mobile ID using Faster Bearers

Some people have questioned if the SMS bearer provides a good user experience and if it is based on a long term technology for Mobile ID. In this blog we try to study this issue and what improvements other wireless communication technologies could provide.

The Challenge

A key issue with the SMS-based Mobile ID is that sometimes Mobile ID uses irritatingly slow wireless communication. This is probably the reason for people’s concerns.

This seems to be related to two circumstances:

  1. the first incoming SMS takes a long time (has high Mobile Terminated-latency) and
  2. if response consists of multiple messages, sending several response messages takes too long (has low Mobile Originated-speed).

Therefore, people have started to look for alternative transport methods for Mobile ID. Let’s check what these are all about and start with the SMS as a bearer.

SMS (Short Message Service—Point to Point)

Mobile ID uses SMS-transport which is the most common transport method when communicating with the UICC card. Short Message Service uses a store-forward protocol and it utilizes the benefits of each mobile technology: low latency in 3G/4G networks and excellent network coverage with 2G technologies.

Additionally SMS is a low cost mature technology and uses vanilla network components like SMSCs. The newest technology alternatives can be defined as the following.

Figure 1  SMS-PP Transport for Alauda

Alternative Transport Methods

By the ETSI Release 9, there are now several standard methods to communicate with the UICC. These mechanisms can be used also to trigger a Toolkit Application and communicate with an applet or to manage the card remotely (Remote Application Management). We split these methods into two groups:

  • Unstructured Supplementary Service Data (USSD) – sessions
  • BIP transport – opportunity for IP-communication
    • Card Application Toolkit Transport Protocol (CAT_TP)
    • HTTP protocol and pre-shared key TLS security Over-The-Air.
    • ETSI TS 102 226 over TCP/IP

The first technology uses USSD and the other, BIP, uses SCWS style communication. Let’s review both groups:

USSD (Unstructured Supplementary Service Data)

USSD connection creates a single interactive data communication session once the connection is established. USSD technology is basically direct packet data connection (182 character packets). Some operators think that USSD has only minor differences with SMS and do not provide both services.


Communication over established session is fast. Sending multiple packet responses is fast.


Session establishment is as slow as the first SMS-PP

The next alternative is the IP-communication.

BIP (Bearer Independent Protocol)

BIP is a mechanism used by some OTA services. The OTA server requests UICC card to open the best bearer channel back to OTA. BIP depends on UICC and handset capabilities. The UICC + SCWS and the handset device exchange HTTP data packet over TCP/IP or over BIP, depending on what is supported by both devices. Today, the BIP is used to tunnel the data.

The most advanced IP-connections are used by NFC applications. NFC requires that the OTA session is initiated using a push message from the OTA server, normally with a traditional OTA SMS. Therefore, NFC applications require a both IP and SMS-PP for OTA-transport.


Communication over established session is fast. Sending multiple packet responses is fast.


Session establishment is as slow as the first SMS-PP

Let’s focus on some specific IP-aware technologies and try to identify what issues these technologies try to solve.

SCWS (Smart Card Web Service)

SCWS technology provides fully-fledged mobile IP infrastructure. Large bandwidth, open Internet protocols, client-server architecture and UICC-based OTA clients will improve the ability to successfully implement OTA solutions.


  1. higher delivery capacity,
  2. higher delivery success rate,
  3. improved scalability, and
  4. ability to dedicate resources to critical use cases.


Session establishment is as slow as the first SMS-PP.


CAT_TP is just another BIP application. The communication bearer solution is the same as for any technology using BIP.


Figure 2 CAT TP Transport for Alauda

It looks like the transport method is not the real solution for the issue. Do we have any other options?

Other Alternatives

How GSMA MobileConnect does the fast communication?

Basically MobileConnect service uses the same SMS-PP OTA channel to UICC as the Mobile ID service. The only difference is that it tries to speed up UICC card interface communication and use single SMS messages without need for message concatenation. Mobile Connect does not actually use faster bearer but just simplified user dialogs.

Improved Mobile ID over SMS

It seems that Mobile ID can be optimized in the same way as MobileConnect does it. We just simplify communication and signature messages.

Solutions for Issue 1: The first MT SMS is slow

  1. Increase Mobile ID SMS service priority – do not store-forward messages
  2. Use 3G or LTE networks when available
  3. Send small messages – check what is really needed to send

Solutions for Issue 2: Sending multiple MO messages is slow

  1. Use 3G or LTE networks when available
  2. Send smaller response messages – check what is really needed to send


In this blog we tried to find if some IP-technology could provide a quick improvement for SMS based Mobile ID solution. We did not find any real benefits using new bearer technologies for Mobile ID.

Instead we found that the improved solution using SMS is the simplest way to speed up Mobile ID communication. It provides amazingly good results in a real 3G network:

  • Average Mobile ID authentication (AP authn to AP accept): 8 seconds
  • Average Receipt after authentication (AP auth to Receipt): 12 seconds

Using SMS as Mobile ID bearer also provide the following benefits, which are not available in BIP / TCP communication:

  1. SMS works with 2g/3G/4G/LTE networks
  2. SMS works with all handsets
  3. SMS can be used inside buildings and far from base stations.

The SMS bearer just works and there is no better bearer for Mobile ID.

Posted in Blog Tagged with: , , , ,

Methics at the 6th NGMN Industry Conference & Exhibition

The 6th NGMN Industry Conference & Exhibition will take place in Frankfurt
(Germany) from 12th to 13th October 2016.

Key focus will be on operator and industry requirements on 5G, initial 5G
technology solutions and related test results, on 5G enabled business
opportunities, use-cases for vertical industries and IPR in 5G.

As a very special highlight, the NGMN Alliance will mark its 10 Year
Anniversary with an evening event celebration on 12th October 2016 (please
see )

Meet you there!

Posted in News

In Layman’s Terms – Alauda Applet Signature Algorithm

Kirmo Hovinmaa, technical writer

The Internet has forced us humans to rethink communication on a fundamental level. The convenience of being able to exchange ideas without necessarily seeing each other face to face or even being on the same continent has brought with it a challenge of trust. In an age where the success of electronic communication is simply assumed and physical print media is being phased out, verifying your identity with a passport or by signing on a dotted line is relatively cumbersome.

Luckily, however, inconvenience is the mother of invention. There now exist technologies that serve as the proverbial ink for signatures in the electronic domain. The signature algorithm used in Alauda Applet allows just about anyone with a cell phone to sign documents in a way that is as secure as flashing your passport and as convenient as typing a few digits on your phone regardless of distances.

These miraculous claims should not go without substantiation, and therein, as they say, lies the rub. The engineers working on this piece of kit absolutely know how the signature algorithm works and can even lay it out in writing, but to someone who lacks their frame of reference, making any sense of all the technical terms and conventions can be overwhelming. I should know, as I don’t have a degree in technology, and in fact lack any form of programming experience whatsoever. Wait, don’t leave just yet! My inexperience presents with it an opportunity.

By explaining how Alauda Applet’s signature algorithm works in a way that I myself can understand, I attempt to build a bridge between the engineers’ and the laymen’s frames of reference. We’re going to be buffeted with some pretty intimidating terminology here, but I’ll be with you all the way. Let’s see if we can’t weather the storm together.

Let’s say I want to sign a contract. Both parties of the contract agree that merely clicking OK on a web browser leaves too large a possibility for identity fraud, but signing wirelessly would still be the most convenient option for all. So I make use of a Mobile Signature Service (MSS), likely provided to me by my mobile operator. The service provider has a whole infrastructure to support signature operations, but what’s relevant for me is that as an MSS user, the SIM card in my phone contains a little program called Alauda Applet.

By verifying my identity once at the mobile store, I have aquired a means to use my phone to receive and open what are essentially padlocks in my image. These locks don’t necessarily make the contents of documents inaccessible; although technically these locks can be used to contain documents in “boxes” that only I could open, this is not done when I want to sign a document. The locks are connected to a key that resides in the Applet. This key does not travel anywhere from the Applet; it merely opens padlocks in my image on documents the Applet has received. Access to that key is protected with a PIN-number of my choosing, similar to but separate from how my whole cell phone is protected.

The connection between my identity and my lock and key allows me to express consent to contracts by opening locks on documents. An open lock in my image can be traced back to my actual identity, since only I have the key to that particular kind of lock. The signature creation process in Alauda Applet can work in a couple of different ways, but let’s reach a basic understanding by covering the most intuitive case, What You See Is What You Sign.

The document I am signing reaches me through my Mobile Signature Service Provider (MSSP). The MSSP sends my phone a signature request, which contains all the text in the document as well as instructions for how the Applet should process it.

blog mssp to phone
Once the Applet receives the request, it calculates a digest of the document’s contents. Digests are essentially (relatively) short, unique series of numbers and letters that from then on can be used to refer to the whole document, and they can be calculated for any text by using various algorithms.

blog first digest
The Applet uses this digest a bit later, but first it lets me view the text I am about to sign on the screen of my phone. Once I confirm that I have read the document, the Applet uses the digest it just calculated to create an entity known as SignedAttributes. This entity contains some objects that help with the signature process and auditing in addition to the digest. The Applet then creates another digest, this time of the SignedAttributes entity.

blog second digest
The second digest that the Applet created is an entity that can be signed by me, so the Applet slaps a padlock in my image on the document and prompts me with the PIN that I protect my key with. Once again, this doesn’t make the contents of the document inaccessible, but rather tasks me with opening a lock only I can open to confirm my identity.

blog locked digest
Once I have entered my PIN, the Applet uses my key to open the lock and sends the entity back to the MSSP along with the opened padlock. The MSSP can verify that it is indeed my opened lock on the document, and then send further data to the contract holder.

blog unlocked digest
I am abstracting the process quite a bit here, but even now some of that may have seemed a bit complicated to someone less technically inclined. Let’s recap what just happened in simpler terms: A program in my phone receives a document that I want to sign along with instructions that say: ”This piece of text needs a signature, do your thing.” I see the contents of the document on the screen of my phone, and the program converts the text into a form that’s easy for it to process and that contains important information for auditing the event. In place of a conventional penned signature, the program asks me to confirm my identity and consent by having me do something only I can do: open a padlock in my image. The converted document, along with important auditing information and my signature, goes back where it came, and the contract holder is informed that the signing took place.

And that’s basically it. There are variations to this process on a case-by-case basis – for example, instead of reading the whole text on the screen of my phone, I could receive just a representation of the document on the screen of my phone, and I could read the document on a computer screen with the knowledge that I am signing a representation of precisely that document. (This is useful for longer documents that would otherwise take up a lot of memory; in fact, the What You See Is What You Sign process can only display very short texts.) However, the idea of me confirming my consent wirelessly with an action that only I can make remains constant.

Posted in Blog Tagged with: , , , , , , ,

MSSP Performance Testing (2/2)

This blog post is follow up for our MSSP Performance Testing post earlier this year.

 Test Results – First Round

The first tests we run were focused on the number of CPU cores. Does limiting the core count reduce performance considerably?

The CPU count seems to have little to no effect on the performance. This definitely indicates a bottleneck in the MSSP application or the system configuration.

Bottleneck Analysis

We used jvisualvm for detecting bottlenecks. This blog post describes jvisualvm usage very well.
The bottlenecks we found were mostly in our logging system and various third party libraries.

The most common problems seem to be calling System.getProperty() method in each request. This causes a global lock.

All in all, jvisualvm seems like an excellent tool for quickly identifying performance issues. It’s extremely easy to use and is packaged with the JDK.

Test Results – Second Round

After fixing the issues identified by jvisualvm, the MSSP throughput improved around 25% (to 150txn/s).
This is a good result for such an easy fix. The next bottleneck is most likely the database configuration in the testing environment.

Posted in Blog Tagged with: , ,