Methics registers “mss” URI Scheme

IANA today registered provisional URI scheme “mss” published by Methics. The “mss” scheme defines the URI for SignatureProfiles used in for requesting mobile signature services from the MSSP Platform. You can find the scheme from:

Signature Profile in Mobile Signature Service

The success of Mobile Signature Service (MSS) is reliant on a feature where an Application Provider (AP) does not need to know, in which mobile operator’s network a user can be found. This feature is called “signature roaming”.

If all reachable mobile users in various mobile networks do not have the same signature capabilities, it is hard for an AP to determine what kind of mobile signature to request from different mobile users. Especially when several different mobile signature services are available. The MSSP can define different mobile signature capabilities of mobile users, but AP should be able to indicate some kind of a signature type/quality to the MSSP. This capability is called the Signature Profile.

By using the ProfileQuery mechanism, the AP can request any mobile user’s Mobile Signature Profiles from a MSSP. Additionally, the AP can use any specific Signature Profile assigned to the user in the Mobile Signature Request.

Usage of Signature Profile

Signature Profile is used in the following mobile signature service operations:

Operation Definition
Signature Request The relying party (or AP) is requesting this signature profile to be used in the processing of the transaction
Signature Request: Signature Profile Comparison If set to “exact”, then the MSSP is asked to match at least one of the specified <SignatureProfile> elements of the MSS_SignatureReq message exactly; If set to “minimum”, the MSSP is asked to use a profile that he feels is at least as good as any specified in the <SignatureProfile> element; If set to “better”, the MSSP is asked to use any profile better than any that were supplied.
Signature Response The MSSP should make a statement of the Signature Profile that was used (optional).
ProfileQuery One or several Mobile Signature profiles supported by this MSSP for the mobile user.

Additionally, the Signature Profile is linked with two other profiles: Registration Profile and Certificate Profile. Registration Profile defines requirements for the registration process and Certificate Profile defines what kind of certificate is created.

Analysis of Signature Profile

ETSI TR 102 206 provides analysis of what is the meaning of the Signature Profile. Basically, the Signature Profile can be described by any means that is found appropriate by both parties (the MSSP and the AP), which can be defined by using URI representation. General requirements for the content of Signature Profiles can be defined as follows:

Information about the registration method and assurance such as:

  • Face to face or remote registration
  • Level of security of user credentials or related protocols
  • Verification and issuance of user’s identity
  • Quality and issuance of keys

Information on the Secure Signature Creation Device (SSCD) technical assurance:

  • Signature policy
  • Technical protection of the SSCD and platform
    • the Mobile SSCD (e.g. SIM card or other secure element), the Mobile Signature Creation Application (e.g. Mobile App) or the MSSP platform (e.g. server-side signature).
  • Accreditation or declaration of conformity with a formal profile
  • User Authentication mechanisms (password, biometric, etc.)

Uniform Resource Identifier (URI) generic syntax has been defined in the IETF RFC 3986.

Signature Profile URI

Conventionally Signature Profile URIs follow the “http URI-scheme (e.g. Alternatively, there are a great number of other schemes available, which could be more descriptive than the http-scheme.

Unifying Signature Profile URI scheme

Today there are no semantic rules on how to construct the Signature Profile URI. Therefore, we need to consider what aspects could define a self-descriptive Signature Profile.

We have found four major aspects, which are:

  1. Commercial name,
  2. Signature Operation (or PKI Operation),
  3. Level of Assurance, and
  4. Secure Signature Creation Device
Signature Profile consists of four major security aspects.

By using these four characteristics, we can form define existing Signature Profile URIs, these URIs are conveniently short and easy to understand their meaning.

Therefore, we recommend to use the new mss-scheme base URI, which would be constructed as follows:

mss:<Commercial service name>:PKI operation:LoA:SSCD

Cryptographic algorithms (RSA, ECC or key lengths) are not included in the base URI. Related details can be added as URI extensions using either query strings (for example “?ECC=true, AlgECC=NIST-256, RSA=true, RSAkeylen=2048”) or URI fragment (#ECC etc.)

Signature Roaming and Signature Profile

It is easier for the AP that they do not need to know the MNO who provides the service. That means that the MSSP can redirect a mobile signature to the correct MNO and use the correct Signature Profile regardless of the number of available Signature Profiles. Therefore we recommend that if the commercial name differs then the MSSP can convert the commercial service name when roaming between MNOs.

Therefore, we recommend that the mobile signature functions, LoAs and SSCDs would be unified at least in same market areas. Basis for these definitions would be:

LoAs Description Notes
LoA2 LoA2 [.extension] Extensions may define additional
LoA3 LoA3 [.extension] requirements like specify identity attributes
LoA4 LoA4 [.extension] or registration mechanism
PKI Operation Description Notes
sign Plain text signing
authn Authentication
encrypt Encryption
pop PKCS#10 PoP
popo CMP/CRMF PoPo
consent Consent signing
anonymous Authentication Restricts identity attributes (e.g. Age)
digest Digest signing

SSCDs Description Notes
sim UICC and SIM cards Including eSIM etc
app Mobile App
se Integrated token (USB, SSP) Removable token
server Server-side signing

Conversion from different commercial names to a complete base URI may also be possible even though we do not recommend it. This would mean easily lots of confusions when the commercial names would need to define all mobile signature capabilities.

FICOM Finland
Anonymous authentication Current URI New URI
Signature of plain text content
Signature of digested content
Issuing consent
Operator authentication service (operator’s internal service) mss:operator:authn:loa4:sim
(or use MNO’s name as the brand).
MID Switzerland

GSMA Mobile Connect
Mobile Connect LoA2
http://mobileconnect/something/LoA2 mss:mobileconnect:authn:loa2:sim

Mobile Connect LoA3
http://mobileconnect/something/LoA3 mss:mobileconnect:authn:loa3:sim


Simplest interoperable URI examples

Smallest Signature Profiles which match every previous schemes
Authentication LoA2 mss::authn:loa2
Authentication LoA3 mss::authn:loa3
Signature LoA3 mss::sign:loa3

Tagged with: , ,

Strong Electronic Identification: scenarios for the future

Today, a person’s ability to prove their identity is seen as an important basis for participation in the society and life in general. In most countries around the world, establishing a person’s identity whether online or offline, is mandatory to access a wide range of services, including education, healthcare, voting, banking, mobile communications, housing, etc.

With the continuing shift from face-to-face interactions to Internet-based interactions in governance, business, and several other areas, the major challenge becomes “how do we ensure a reliable and trustworthy match between an online identity and a physical one?” In addition, as mobile devices become the primary and dominant device for communication and Internet access, another challenge is understanding “What strong electronic identity solutions could be implemented and how do such solutions support a mobile-first future?”

These constraints and questions demand solutions that are not only mobile-based but also provide the highest Levels of Assurance (LoA) to achieve a similar level of trust and acceptance as a trusted identity document used in the physical world.

In addition, as a stakeholder looking to implement a strong electronic identity solution, another decision gate is universality and interoperability of the solution. In the world today, we have seen several implementations fail due to lack of interoperability. The world is filled with identity silos which are not suitable for a truly global Internet where services and people are dispersed in several countries. With increasing service and person mobility as well as cross-border trade and collaboration, stakeholders must include the design of universality at the foundation of the solution.

Many electronic identity solutions have been implemented around the world including simple 2FA solutions (e.g. using OTP/TANs); symmetric cryptography based solutions such as GSMA’s Mobile Connect solution; PKI based solutions including those implemented on USB keys, physical e-ID cards, SIM cards (Mobile PKI), Server-side signing/Remote signing (where user PKI credentials are stored in a cloud-based HSM) and different implementations of software-based certificates (e.g. smartphone applications).

Technically, solutions that make use of PKI certificates, tamper-resistant hardware tokens and strong identity verification processes are found to be most secure and provide the highest levels of identity and authentication assurance. Therefore, tamper-resistance of the security token will continue to influence key choices in the design and implementation of strong electronic identity in the future.

On the other hand, not all PKI based implementations are particularly suited for use in mobile environments. A mobile-focused approach will take advantage of the reach, usability, built-in technologies and popularity of mobiles as primary communication devices used by citizens. Strong electronic identity solutions must, therefore, be designed to support available mobile technologies to succeed.

Mobile PKI solutions promise the most security for Mobile environments albeit with less flexibility based on today’s technologies. New developments in the mobile space such as the expected surge in the number of devices with tamper-resistant, PKI eUICC cards, promise a huge opportunity for the mass implementation and delivery of strong electronic identity to end users.

Other proposed solutions such as TEE-based electronic identity is another promising prospect for delivering strong electronic identity to citizens. Used with biometrics, it promises more flexibility to e-ID implementations, however technology standardization, and maturity of TEE implementations will take time.

ETSI defined Mobile Signature Service (MSS or more commonly Mobile ID/PKI) as “A Universal method using a Mobile device to confirm a Citizen’s intention to perform a Transaction.” At the core of Mobile PKI solutions is universality, allowing stakeholders to design electronic identity solutions that resolve the currently incompatible identity silos which encompass the Internet.

Given the maturity, available open standards and interoperability frameworks available, Mobile PKI solutions are well suited to provide a secure, tamper-resistant and universal strong electronic identity solution. Stakeholders will do well to adopt Mobile PKI solutions to implement mass market strong electronic identity solutions that will scale into the future.


  • eUICC – Embedded Universal Integrated Circuit Card (or commonly known as eSIM)
  • HSM – Hardware Security Module
  • OTP – One Time Passwords
  • PKI – Public Key Infrastructure
  • SIM – Subscriber Identity Module
  • TAN – Transaction Authentication Number
  • TEE – Trusted Execution Environment


  1. Agbede O.M. “Strong Electronic Identification: Survey & Scenario Planning.” Aalto University Master’s thesis, August 2018.
  2. Clarka J., Dahana M., Desaia V., Iencob M., Labriollec S., Pellestorc J., Reidb K. and Y. Varuhakic. “Digital Identity: Towards Shared Principles for Public and Private Sector Cooperation.” A joint World Bank Group, GSMA, Secure Identity Alliance Discussion Paper, July 2016.
  3. Sandeep T., Jan-Erik E., and P. Laitinen. “On rehoming the electronic id to TEEs.” Trustcom/BigDataSE/ISPA, Vol. 1. IEEE, 2015.
  4. Secure Identity Alliance. “Enabling the eGovernment 2020 Vision: The Role of Trusted Digital Identity.” A research report and position paper by the Secure Identity Alliance & Boston Consulting Group, March 2014.
Tagged with: , ,

Secure Mobile Signature Service Platform

The MSSP standards were originally defined at ETSI at the beginning of this millennium. One of the MSSP design key objectives was a secure system by design. This blog unwraps those underlying design principles.

General security principles such as confidentiality, integrity, and availability do not change over application area. These principles have been described in the OWASP Development Guide. Therefore, we have used these security principles in this blog.

Design decisions should be practical and easy to understand. However, we should question and strengthen the security design continuously. For example, it’s a good practice to implement data validation to include a validation routine for all forms of input and service access. However, it is more advanced to see data validation at each tier for any input, joined with appropriate error handling and access control based on demand.

Asset Classification

To be able to protect a sensitive data it must be classified. The security controls are based on this classification. The key security assets in the MSSP solution have been divided into four groups:

  1. Mobile user assets
    1. Mobile user identity attributes
    2. SIM card access credentials (SIM card’s SSD OTA keys and counters)
    3. WPKI protocol credentials (Alauda encryption keys and counters)
    4. Mobile user logs
  2. Registration and validation controls assets
    1. Resource access credentials (CA, etc.)
    2. Identity validation registers etc.
    3. Registration logs
  3. Application Provider access assets
    1. AP access credentials
    2. AP access logs
  4. System credentials
    1. Remote system credentials (DB passwords, CA connection credentials)
    2. Local identity (TLS credentials (server/client) and MSSP identity credentials

Especially logs are often forgotten from the classification.


When we design controls to prevent the MSSP service abuse, we try to identify the most likely attackers:

  1. Fraudulent staff or developers,
  2. Random attacks, such as side effects of bugs or viruses, worms or Trojan attacks,
  3. Motivated criminal attackers,
  4. Criminal attackers without motive against the service, such as occasional offenders, etc.

Security Architecture

The architects of the original MSSP standards at ETSI have constructed an MSSP design to adequately cover risks from both typical usage, and from extreme attack. The MSSP solution vendors are responsible to implement their solutions utilizing these principles and other relevant security principles.

The MSSP security architecture refers to the following fundamental pillars:

The MSSP must provide controls to protect the confidentiality of information, integrity of data, and provide access to the data when it is required (availability) – and only to the right users.

All provided services need to be considered from a security point of view:

  • Are the feature requirements safe?
  • Can some process have an unknown attack surface?
  • Could the process leak information?
  • If there were an adversary, how would it abuse this feature?
  • Is the feature required to be enabled by default? If so, are there limits or options that could help reduce the risk from this feature?

The MSSP system architecture design shall provide security considerations in each and every new feature, how the risks are going to be mitigated, and what was actually done during implementation or deployment.

Security architecture starts on the day the business requirements are modeled, and never finishes until the last copy of your application is decommissioned. Security is a continuous integration process, not a one-shot task.

MSSP security principles

The MSSP security relies on the following general information security core principles:

  1. Confidentiality – Allow access only to data the user is permitted.
  2. Integrity – Ensure data is not altered by unauthorized users.
  3. Availability – Ensure services are available to authorized users on demand.

The following MSSP security principles are derived from these three core principles.

1. Principle of minimal attack surface

The aim for MSSP security is to reduce the overall risk by reducing the attack surface area. Therefore,

  • AE MSSP provides only an AP access to the service, the AP needs to use mutual TLS encryption and only well-defined messages are permitted. All other traffic including wireless, registration and certification services are handled elsewhere.
  • ME MSSP takes care of administration and registration. For example, intrusion detection is easier when there is no high volume signature request traffic in the same server. Only standard SOAP traffic protected with TLS is allowed between MSSPs. Special VPN connections and security controls can be added when there is no high service load at the ME servers.
  • HomeMSSP holds the key security assets. Therefore, the HomeMSSP locates in the high-secure zone. All access from APs to the HomeMSSP comes over TLS secured SOAP messages via AEs.

2. Principle of secure defaults

MSSP solution itself contains extensive security mechanisms for initialization and administration of user security. There are no defaults for a user. Signature based authentication, certificate based identity management, revocation procedures, and validation interfaces provide the basis for the security.

All default credentials can be easily detected and altered at the MSSP solution at installation time. Additionally, the MSSP solution provides excellent tools to protect all application credentials against accidental disclosure or hostile out digging.

3. Principle of least privilege

The principle of least privilege recommends that accounts have the least amount of privilege required to perform their business processes. This encompasses user rights, resource permissions such as CPU limits, memory, network, and file system permissions.

For example, if a middleware server only requires access to the network, read access to a database table, and the ability to write to a log, this describes all the permissions that should be granted. Under no circumstances should the middleware be granted administrative privileges.

The overall MSSP solution architecture follows the principle of least privilege which requires that every module (such as a process, a user, or a program) must be able to access only the information and resources that are necessary for its legitimate purpose.

4. Principle of Defense in depth

Defense in depth is an information security principle in which multiple layers of security controls are placed throughout the MSSP system. The principle of defense in depth suggests that where one control would be reasonable, more controls that approach risks in different fashions are better. Controls, when used in depth, can make severe vulnerabilities extraordinarily difficult to exploit and thus unlikely to occur.

In the MSSP system, this principle takes the form of system splitting between AE, ME and HMSSP. Each MSSP implements its own security controls and only controlled messages flow through the system.

5. Principle of fail securely

MSSP may fail to process transactions for many reasons. At the same time service should be user-friendly and secure. In many cases, the service tries to be extensively helpful and allow user mistakes as long as possible. Alternatively, the service could fail in every circumstance when some detail did not match.

The MSSP solution tries to implement high-security service with an excellent user experience. Therefore, the fail management has used the following principles:

  1. Create intuitive and simple user interface – minimize places for user errors.
  2. Define detailed service interface for the AP – minimize misunderstandings
  3. Prepare detailed failure logging – disclose only relevant parts to outsiders
  4. Make failures monitorable – monitor failures as well as normal usage

6. Principle of don’t trust services

Many MSSP deployments need to utilize the processing capabilities of third party partners like CA or Registration Agents, who may have differing security policies and posture than the MSSP operator. It is unlikely that the MSSP can influence or control any of these third parties.

Therefore, MSSP does not provide an implicit trust to any external systems. All external systems are treated in a similar fashion.

7. Principle of separation of duties

A key fraud control is separation of duties. For example, if the AP can send signature requests to the AE MSSP it cannot also send requests directly also to the HMSSP. This prevents the AP from requesting many MSSP simultaneously and claiming some requests never succeeded.

Certain AP roles like RA and CA have different levels of trust than normal Application Providers. In particular, AP accounts used for the service administration are different to normal APs. In general, normal APs do not have the same roles as any administrator.

8. Principle of avoid security by obscurity

Security through obscurity is a weak security control, and nearly always fail when it is the only control. This is not to say that keeping secrets is a bad idea, it simply means that the security of key systems should not be reliant upon keeping details hidden.

All MSSP interfaces are based on open standards and interfaces are well documented. No obscurity is used for any functionality. For example, the MSSP security does not rely upon knowledge of the source code or the specification being kept secret.

A practical example is Linux. Linux’s source code is widely available, and yet when properly secured, Linux is a hardy, secure and robust operating system.

10. Principle of keep security simple

Attack surface area and simplicity go hand in hand. MSSP developers have avoided the use of complex software architectures when a simpler approach or a design pattern is available.

For example, although it might be fashionable to use Java Enterprise Edition for business logic implementation, Java EE has been discarded in the Kiuru MSSP because it adds software complexity and opens unknown number of new attack surfaces for attackers.

11. Principle of fix security issues properly

Once a security flaw has been identified, it is important to understand the root cause of the issue and to prepare a test for the issue. When some specific design pattern has been used, it is likely that the same security issue is spread among all code base. The right software resolution, which does not a return to a former or less developed state, is needed.

In the Kiuru MSSP development process this means three things:

  1. Kiuru MSSP development uses Continuous Integration development practices. Each security fix check-in is verified by an automated building engine in several software branches, and several different test sets are executed automatically and reported to a developer multiple times per day.
  2. All changes are logged into a revision control system. Any change can be tracked afterwards. If the fix has been applied multiple times, all those fixed instances can be located.
  3. Additionally, software vendors should refrain from ad-hoc changes during software maintenance, especially during night time or weekends. Therefore, it is essential to have proper built-in controlling mechanisms in the software. In the Kiuru MSSP, we use a built-in scripting language for security controls and temporary workarounds.




Methics launch new Applet for remote eIDAS-compliant signatures.

Methics launched a new SIM applet, the Alauda B17 Fortress; a new addition to our growing product portfolio to cater for low-cost standard JavaCard UICC cards.

Remote signing with Alauda B17 is based on PKI and complies fully with standard PKIX specifications. The MSSP generates the PKI key pair and uses a secret key sharing mechanism to split the private key between the MSSP server and the standard JavaCard SIM card in end-user devices.

eIDAS-compliant PKI Signatures are produced by the server-side Kiuru MSSP platform after user consent (Click-OK or PIN entry) on the Alauda B17 applet.

Remote signing with Alauda B17 applet has multiple benefits:

  1. B17 applet works on rudimentary JavaCard UICC cards – no PKI hardware is required on the card.
  2. B17 applet shares the features available on the Alauda P38 WPKI Applet including an identical user interface and multi-language support.
  3. B17 supports Click-OK and PIN user journeys similar to GSMA CPAS8.
  4. B17 provide equal functionality with CPAS8 and high level of security.
  5. Kiuru MSSP platform works w/o an HSM to make the actual signatures.

Contact us to learn more about how we could help you leverage your assets to become a strong mobile ID provider.

Tagged with: , ,

Methics deliver new Cassandra based logging solution for Clustered MSSP environments.

The Kiuru Cassandra Logging solution offer distributed, scalable, robust and fault-tolerant logging in clustered MSSP environments.

Logging to a Cassandra database rather than to local MSSP server files provides up to 20 to 40%  performance boost in a clustered MSSP environment. It also comes with the added advantage of being able to extract all MSSP logs on specific signature sessions from the same location (database) without needing to login to individual MSSP servers.

Read more in the Kiuru Cassandra Logging Product Factsheet available here.

Tagged with: , , ,

Mobile ID: An Enabler of Sustainable Development

To be able to realize the sustainable development goals (SDGs) set by the United Nations, countries need to be able to deliver services to the whole of their population. One major challenge facing this is that face-to-face services provisioning can only go so far. Therefore, there is a need for government to deliver innovative services over the internet, so-called eGovernment.

For Government to be able to start these new services, there has to be some way to reliably and lawfully authenticate citizens. In fact, person authentication today (be it online or offline) forms the basis for which citizens access services and participate in the society and life in general. Unfortunately, a lot of countries face a daunting challenge to provide digital identity solutions that are cost-effective, easy to deploy and implementable for mass market usage in the midst of the huge number of technologies available.

Today, the World Bank estimates that more than 1.1 billion individuals do not have official proof of their identity. There is thus a race against time for countries to put systems in place to ensure that these people are not left out of the society completely. Bodies such as the World Bank, ITU, etc. are recommending mobile phone-based Identity solutions as the select choice for sustainable, scalable and cost-effective mass-market digital identity solution for citizens. In fact, the Identification for Development (ID4D) initiative of the World Bank exists solely for the purpose of increasing the number of people with official IDs around the world.

Among the selling points given for Mobile-based identity solutions is the proliferation of phones and the fact that a lot of people, especially in developing countries access the internet and invariably services via their mobile, i.e. 80% of all persons who uses the internet in India does so using their mobile phones and similar high figures in other countries such as Nigeria, Kenya, Pakistan etc. Thus, a mobile-based identity, available to the users through their phone at all times make the most sense. It posits that solutions like mobile ID will enable users to identify themselves seamlessly to gain access to government services.

Today, there are lots of mobile identity solutions including Mobile ID (mobile PKI), Mobile Connect, Mobile Authenticator apps and many other app-based mobile identity applications. Of all the so-called mobile identity solutions available today, Mobile ID offers definitely the most secure, tamper-resistant and high assured identity solution which competes favorably with internationally recognized smartcard-based e-ID card solutions. This is because Mobile ID itself is a Smartcard-based solution conveniently leveraging the tamper-resistant crypto SIM cards in phones, and eliminating the need to carry extra devices in Smart Cards or crypto tokens and card readers.

In many developing countries, Mobile Network Operators have mandatory requirement to carry out registration of all their subscribers. This provides an opportunity for MNOs to become a source of strong digital identity within these countries through Mobile ID solutions and provide a path for the previously undocumented people to gain officially recognized IDs required to enable them become full participants in the society.

Mobile ID solutions such as the one offered by Methics is by design open standard based, roamable, interoperable and usable across borders, fully subscribing to and supporting global and regional single digital identity markets enabling faster cooperation and trade between countries.


  1. World Bank’s Identification for Development (ID4D) Initiative.
  2. World Bank (2017). Technology Landscape for Digital Identification (English). World Bank Group. Retrieved from:
  3. ITU (2017). Mobile identification: Implementation, challenges, and opportunities. International Telecommunication Union’s Telecommunication Development Bureau. Retrieved from:
  4. GSMA (2017). Driving Adoption of Digital Identity for Sustainable Development: An End-User Perspective Report. GSMA Digital Identity. Retrieved from:
Tagged with: , ,

Laverca 2.1.0 Released

The open source MSS library Laverca has been updated for extended support of Advanced Electronic Signatures (AdES).

The new release contains support for the mobile signature service profile query extension usage. Now the AP application can query end user certificates from the MSSP before constructing the AdES signature request. This simplifies significantly signature request processing.

The new release supports also PAdES making PDF documents suitable for AdES.

You can find the latest Laverca release here

Tagged with: , , ,

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 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?

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 (about thousand 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 on an Infineon chip with faulty firmware?

SIM card factories do not want to lock themselves on a single hardware vendor. Therefore they are not reporting to their customers which chip factory made chips 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.

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 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 (, one for document signing (, and one for enterprise services ( 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.


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.


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.

Tagged with: , , , , , downtime

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