ROCA – Vulnerable RSA Key Generation on Some Smart Cards

Latest news on smart card based security solutions tells that once again one vendor has produced low quality firmware for RSA key generation. What makes it even worse is that this hazard was caught up only after cards had been delivered for at least 5 years.

These faulty smart cards were properly tested and certified. Passing certification with a major fault does not either foreshadow good protective covering for certified products. Or maybe the certification did not even cover the most important characteristic of PKI in the first place?

https://crocs.fi.muni.cz/public/papers/rsa_ccs17

At the time of this writing, first tools to detect vulnerable keys have been made available.

Looks like some of 1024 bit RSA keys are very vulnerable, and factoring attacks on them can be very low cost (USD 40 to 80 per vulnerable key.) As the fingerprint algorithm is very cheap to perform (tens of fingerprints per second per CPU), finding vulnerable public keys is easy if one has large database of public keys available. This is why several public directories of citizen certificates were closed past summer 2017.

These vulnerable keys were generated with an algorithm that unfortunately often produced keys far easier to break than in normal case. This does not make breaking good quality RSA keys any easier than before, just that there are now likely millions of keys that are easy to break.

What about PKI SIM cards?

How to find if a SIM card is made by the faulty vendor?

SIM card factories do not want to lock themselves on a single hardware vendor. Therefore they are not reporting to their customers which card factory made their cards in a given card batch. Infineon is one of the big suppliers of chips, and therefore likely to be on any SIM vendor’s card, and having been deployed on operator network.

Usually Mobile ID systems do not publish their user certificates in a directory (like LDAP) enabling this kind of quick vulnerability search, and impersonation attack. However making a targetted attack is still possible – malicious service requests Mobile ID signature, and in the signature response there is user’s certificate with public key which normally is used to verify the signature response. Now a malicious service cheks if the public key is breakable, and commences attack.

How MSSP system can protect users with vulnerable cards?

MSSP operator can run an offline check of all generated keys, and disable users with detected vulnerable keys.

When a service provider (AP) calls signature service, the MSSP can check that the target user does not have vulnerable key.
If this vulnerability is detected, signature service can be refused.

Similar online check can be done for key generation.

Today Kiuru MSSP provides these key material verification tools.

Is ECC vulnerable?

Alternate PKI technology to RSA keys is ECC.
ECC is not vulnerable for this issue nor for any other known issue either.

Posted in Blog, Technology Tagged with: ,

Number of PKI Keys in Mobile ID Service

One of the main discussion topics in new Kiuru MSSP deployments has been the number of keys on the SIM card. Should there be a separate key for signing and authentication? How many PINs can the user actually remember? What kind of certificates is required?
The number of required keys is the theme question in all new Mobile ID deployments. The challenge is to define aspects, which affects or restrict the number of keys.
This article tries to elaborate the question and various options in real wireless PKI systems. We claim that no more than 5 keys are needed in a typical set-up. Lets define basic key terminology at first.

User Identity Binding

A user identity is defined in the certificate Subject and the certificate binds the Subject and the public key. PKI cryptography binds the public and private PKI keys. In the Mobile ID system, the PKI key pair is generated on the SIM card. The private key never leaves the SIM card and is protected by a PIN; multiple keys can be protected by a single PIN. The public key is sent to the MSSP and the MSSP takes care of the certificate. Figure 1 depicts these relations.

Public_key_Subject_binding.

Public key and Subject binding.

The Kiuru MSSP system has two profiles which control key and identity bindings: Registration Profile and Certificate Profile. A user registration process cycle generates from one, up to five keys. For example, a registration process definition in the MSSP server’s registration adapter for 3 key registration consists of three Registration Profiles — one for authentication key (http://alauda.mobi/authn), one for document signing (http://alauda.mobi/nonRepudiation), and one for enterprise services (http://alauda.mobi/EnterpriseAuthn). Each one of these registration profiles generates a new key and requests a corresponding certificate from a CA.

This means that by default, the MSSP requests a certificate for all generated keys using the corresponding certificate profile. The certificate profile defines for example the certificate content and the CA for each certificate.

The Subject content consists of a set of attributes. Commonly, there are two kinds of Subjects aka Distinguished Names: pseudonym and real name certificates. Pseudonym certificate essentially defines only a unique subject without user’s real name attributes. Its the Relying Party’s responsibility to map the Subject to a real identity.

Real name certificates are an alternative approach. A real name certificate contains both user’s name (First name, Surname, Initials) and a unique serial number/identifier. In this case the Relying Party gets basic identity attributes and does not necessary need to verify user identity any further. Note that typically real names are not distinguished and in practice, the pseudonym and real name certificates should be handled equally.

As a conclusion we can say that the user may have as many identities as there are key pairs, the Subject does not restrict anyhow the number of keys.

Level of Assurance

Level of identity Assurance (LoA) depends on a trustworthiness of the registration process and the strength of the used cryptography technology. Kiuru MSSP Mobile ID solution supports three LoAs (LoA 2, 3 and 4). Different LoAs can be obtained easily by using different key lengths and registration processes.

Alauda applet’s LoA2 authentication is based on the same idea as the GSMA Mobile Connect LoA2 one-click-OK authentication. No PIN is asked and all user needs to do is press OK button. LoA3 and LoA4 user experience and technologies are the same and only the registration process assurance and the certificate content differs. LoA3 is used typically for enterprise applications and LoA4 for financial or national identity level applications.

Level of Assurance support requires multiple key support. Typically the LoA3 certificates are issued by user’s employer or bank and LoA4 certificate issuer is the government.

Key and PIN

When the key is generated, the user is asked at first to define a PIN and then enter the PIN again for confirmation. If two keys are generated, then user must enter a PIN altogether four times. This may be considered as a complicated user experience.
Alternatively, only authentication key is generated in the registration phase. In this way the user can generate the other keys afterwards by using the authentication key and a self-care portal. For example document signing keys can be generated only if user needs them. In this case we need to consider also user experience, when additional actions are needed from the user or how user can handle PINs.
Key and PIN binding is flexible and MNO may select various key grouping models. Number of PINs do not need to restrict number of keys anyhow.

Key Algorithms

Security of key algorithms are continuously under careful consideration. There are multiple parameters which needs to be considered when algorithm strength is defined. These are parameters like algorithm itself (RSA, ECC), key size (RSA: 1024-2048, ECC: 250-800) or used hash size (SHA-1 – SHA-256). Anyhow, the most important constraint shall be the resulting memory consumption on the UICC card.
Fortunately, Alauda applet key storage mechanisms and applet size are so small that memory consumption of the Alauda applet does not typically restrict number of keys.

User Experience

In most of cases we have been involved in, the user experience is a cultural question.

  • How many PINs can the user remember?
  • How many keys are needed initially?
  • Is it ok to run registration process in multiple separate cycles or in a single cycle?
  • How Helpdesk can advice users?
  • Service pricing?
  • Complexity vs security and competing technologies?

The most important decisions are made when these questions are answered. Success of the Mobile ID service depends on how the initial service model has been set-up to provide convenient and secure user experience, and these benefits must be higher than what competing technologies can provide.

Selecting Key Configuration

The Alauda P38 and Kiuru MSSP solution default configuration supports up to 5 different keys/key groups. The number of keys can be extended up to 16 keys per SIM card with configuration parameters. In practice, more than 5 keys is so rarely used that our conclusion has been that 5 keys match with the most of PKI systems and 5 keys are easier to manage.
We can organize keys for example as the following:

1 key

2 keys

3 keys

4 keys

5 keys and

One key is used for authentication (LoA3/4).

The same key can also be used for document signing. This is done by adding “nonRebudiation” key usage to the certificate.

One key is used for authentication and the other is used for document signing (LoA3/4).

One key is used for authentication and the second is used for document signing (LoA3/4).

A third key is used for LoA 2 on-click applications.

One key is used for authentication and the second is used for document signing (LoA3/4).

The third key is used for private corporate authentication (LoA3).

The fourth key is used for LoA 2 on-click applications.

One key is used for authentication and the second is used for document signing (LoA3/4).

The third and the fourth keys are used for private corporate authentication and signing applications (LoA3).

The fifth key is used for LoA 2 on-click applications.

1 PIN

2 PINs

3 PINs

4 PINs

5 PINs

Each key has its own PIN so there will be one key group.

Each key has its own PIN so there will be two key groups.

Each key has its own PIN so there will be three key groups.

The third PIN is permanently empty.

Each key has its own PIN so there will be four key groups.

The fourth PIN is permanently empty.

Each key has its own PIN so there will be five key groups.

The fifth PIN is permanently empty.

1 PIN

2 PINs

2 PINs

3 PINs

Both keys has the same PIN so there will be one key group.

2 PINs, one each for authentication and document signing respectively.

On-click Key only requires an OK click to proceed with transaction (no PIN required).

Same PIN is used for both Authentication and document signing and another key is used for enterprise authentication.

2 PINs, one each for authentication and document signing respectively. A third PIN is used for enterprise authentication and signing applications.

Posted in Blog Tagged with: , , , , ,

methics.fi downtime

We experienced some downtime on the office internet connection yesterday and today morning.
We are now back!

Posted in News

Advanced Electronic Signatures and Mobile ID

What are Advanced Electronic Signatures?

An advanced electronic signature (AdES) is an electronic signature that meets the requirements defined by the EU Regulation No 910/2014 on electronic identification and trust services for electronic transactions. This regulation is under a standard framework known as eIDAS-regulation and the most important standards for Mobile ID services are CAdES and XAdES.

For an electronic signature to be considered as advanced, it must meet several requirements:

  1. The user that has signed a document (signatory) is uniquely identified and linked to the signature. This is done with signatory’s certificate.
  2. The signatory has sole control of the signature creation data i.e. a private key is used to create the electronic signature and the private key is protected with a signatory’s PIN.
  3. The signature can identify if its accompanying data has been tampered with after the message was signed. This property is provided by CMS standard and asymmetric cryptography.
  4. If the signed data has been changed, the signature verification fails. This property is provided by CMS standard and asymmetric cryptography.

Advanced electronic signatures are based on one of the Baseline Profiles that have been developed by the European Telecommunications Standards Institute (ETSI). These are:

  • XAdES, XML Advanced Electronic Signatures is an extensions to W3C XML-DSig. XML-DSig uses Cryptographic Message Syntax (CMS) for signature
  • CAdES, CMS Advanced Electronic Signatures is also an extensions to signed data defined in CMS.
  • ASiC Baseline Profile. ASiC (Associated Signature Containers) specifies the use of container structures to bind together one or more signed objects with either advanced electronic signatures or time-stamp tokens into one single container (a zip file).

Additionally eIDAS regulation defines digest formats and special signature application standards like PAdES for pdf-document signing.

How to create Advanced Electronic Signatures with Standard Conformance?

Standard conformance requirements have been defined in the document like Electronic Signatures and Infrastructures (ESI); CAdES Baseline Profile (ETSI TS 103 173).

B-Level

Mobile signatures have B-Level (basic level) conformance fulfilling profiles:

  • CAdES-BES when the signature-policy-id attribute is not present and
  • CAdES-EPES when the signature-policy-id attribute is present.

This is the base profile Kiuru MSSP uses by default. Therefore we can claim that Kiuru MSSP default configuration is conformant to CAdES B-level.

T-Level

T-Level can be achieved in two ways: Application Provider uses external Trusted Time Provider or MSSP (as a Trust Service Provider) generates a time-stamp token. The time token proves that the signature itself actually existed at a certain date and time. This time-stamp is included into the signed data.

MSSP acting as a Trusted Service Provider can be done by connecting Kiuru MSSP with a trustworthy time source aka Time Stamping Authority. In this case Kiuru MSSP can claim T-Level (Trusted time for signature existence) conformance.

Other

Additionally CAdES Baseline Profile defines two more advanced profiles, which are LT-Level (Long Term level) and LTA-Level (Long Term with Archive time-stamps) conformance. Currently these are out of Kiuru MSSP product’s scope.

How to create Advanced Electronic Signatures with Mobile ID?

Advanced electronic signatures basic profiles are CMS signatures with well-specified attributes. The only attribute which may need some extra work for the B-level is the signatory identifier (certificate). Typical Application Provider XAdES software implementation requires a complete certificate chain beforehand and therefore the certificate chain should be available.

This means that before you can request a CAdES or XAdES signature, you need to either authenticate the user with user’s signing key or request user’s signing certificate by other means. Anyhow, this is not a problem for the most of use cases.

For the T-level implementation, the trustworthy time provider is the key challenge. Typical solution is that the MSSP integrates a common timestamp provider for all application providers.

So the advanced electronic signature is requested by preparing signature data and by requesting a standard mobile signature for the data to be signed (DTBS). The MSSP sends the DTBS to the WPKI applet and you can sign the request similarly as a normal authentication request. For your convenience we have added an example XAdES implementation to the Laverca MSSAPI library (GITHUB).

Posted in Blog Tagged with: , , , ,

Laverca Adds Partial Support for XAdES Signatures

XAdES is an XML Signature extension that allows the use of Advanced Electronic Signatures. Laverca 2.0.1 adds a partial support to XAdES in a form of an example using the Esig DSS library.

You can find the latest Laverca release here.

 

Posted in News Tagged with: ,

How to make interoperable authentication applets on SIM cards?

The interoperability of SIM card applets (SIM Toolkit applications) is an important requirement in today’s mobile communication business. It is normal practice for MNOs to have SIM cards from different SIM vendors. These different cards come with different characteristics including differences in ETSI library versions, Java Card versions, GlobalPlatform API releases etc. The SIM cards are highly standardized in the ETSI Smart Card Platform (SCP) technical specifications. Cryptography and Java Card technologies are also highly standardized even though these technologies have been evolving for a long time. The common problem is that there are still small hidden obstacles and differences in the card platform implementations that every new software must be properly tested and verified.

For the purpose of this blog, we have identified two different legacy approaches to solving SIM toolkit application interoperability issues in mobile communication business.

The first approach is to write detailed specifications in ETSI or in other standardization forums. The GSMA Mobile Connect specification tries to solve CPAS8 applet interoperability in this way. The CPAS8 applet specification has only small number of options and the specification is very detailed. SIMalliance has also published corresponding “Mobile Connect SIM Applet Interoperability Stepping Stones” specification for the CPAS8 applet. The biggest pro of this approach is that the specifications become industry standards meaning anyone can use the specification to develop an authentication applet. This approach is good when a company has enough development resources to follow yet another specification and related conventions. However, the con of this approach is that industry specification and standardization endeavor often takes long, produces large documentation that is sometimes difficult to read/understand and often times, does not cover everything (covers only the most common interoperability issues).

The second approach is the one taken by some SIM card vendors. SIM card vendors have a slightly different approach for interoperability. Gemalto (GTO) has a VMAC applet certification procedure and Giesecke & Devrient (GD) has a WIB applet certification procedure. Pro of this approach is that someone makes some business by checking the applet interoperability and therefore quality control is higher than when vendors just follow new GSMA/SIMalliance specifications. Con in this model is that the applet issuer like GTO or GD will be better positioned in the applet (and SIM card) market than other players. They can control the speed of new certified cards and monitor the other vendor’s products etc.

Methics takes a new approach to the interoperability issues. The Alauda Applet was developed with interoperability in mind; hence the applet supports cards from all SIM card vendors. An accompanying testing tool – the AlaudaTool – is provided in the applet package for applet/card interoperability testing. The pro of this approach is that you can easily test various product combinations and get clear test reports quickly. It is also cost efficient to deploy applets on every possible new SIM platforms. Con is that the testing tool depends on the applet specification and it is quite hard to develop new tools. To minimize required new development work for each new applet specification we have developed an applet test framework and nowadays we can just define new applet functional tests by just adding new simple Java JUnit tests.

Posted in Blog Tagged with: , ,

MNOs – Enablers for Mobile Signature Services

Mobile Network Operators (MNOs) across the world are central to the adoption and deployment of Mobile Signature Services such as Mobile ID and Mobile Connect. The purpose of this blog is to describe how uniquely placed MNOs are in driving change in authentication services on the internet and also profit from it.

The need for a strong authentication based user account management for service providers cannot be overemphasized. In the last couple of years, the use of authentication methods such as username/password combination, one-time passwords (OTP) have been proven to not only be weak but to be out of date in the 21st century web applications. Time and time again, we have read stories of massive account breaches or been victims ourselves of privacy breaches. The world understands that there is a need for better authentication solutions than username/password and MNOs are in the right position to solve this niggling headache that is refusing to go away.

Before now, the solutions that were prescribed, were either secure but with bad user experience or designed with usability in mind but with too many security holes to be usable. Another problem of these solutions was that they were not scalable. Therefore, they find more usage in enterprise applications rather than mass market adoption.

Mobile Signature Services

One solution which is not only highly secure but also scalable, with good user experience is digital signature based mobile authentication solution. This suite of solutions is referred to as Mobile Signature Service (MSS) or simply Mobile ID.

Mobile Network Operators are an important player in Mobile ID business. They are enablers for the business and as such, can use their unmatched position in the market to create new revenue streams for their business as well as drive adoption of better authentication solutions on the internet.

MNOs, provide highly secure SIM cards that host the applets which enable mobile ID services. Today, the SIM card is one of the most secure and widely spread devices owned by the people around the world. The SIM card is tamper proof and follows even the most stringent smart card security requirements. Yet this highly secure device is completely owned by MNOs and is already in the hands of billions of people around the world (at last count, over 4.5 billion subscribers).

Another important attribute of MNOs in this industry is “Know Your Customer” (KYC). MNOs will know their customers – In fact, in most countries of the world, especially in developing countries, including Nigeria, Pakistan, Kenya etc. a subscriber must register with their MNO on the activation of their mobile subscription be it prepaid or postpaid. This offers MNOs the unique opportunity of becoming Identity Verification Service Providers.

With the knowledge of their customers and SIM cards already in the hands of subscribers, MNOs can deploy MSSP solutions to not only offer Identity Verification Services but also become Authentication and Secure Communication Providers. Thus, with their distinctive placing, MNOs can utilize their unique assets to provide authentication services to web service providers.

Internet of Things

There is also an opportunity for MNOs in this era of Internet of Things (IoT). Today, across the world, we are hooking more and more devices to the internet including important infrastructure devices such as smart meters, traffic lights, weather sensors, CCTV cameras etc.

This presents MNOs with a fantastic opportunity to become managed security solutions provider for IoT. Through mobile ID solutions, MNOs can create authentication and secure communication channel for secure IoT communication. In the future, this will become an even easier proposition for MNOs with the development of eSIMs. MNOs just have to be Agile in grabbing this opportunity.

In conclusion, it seems like the MNOs are sitting on a gold mine of opportunities. It is surprising that MNOs are slow in taking advantage of this opportunity today. We are convinced that with the unique position of the MNOs, mobile signature services offers them a future-proof revenue stream.

Posted in Blog Tagged with: , , ,

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

4G

4 – 7

3G

6 – 9

2G

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

4G

3.2

3G

5.0

2G

14.3

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 Tagged with:

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
Top