PKI Security: Smartphone Apps vs. SIM applets

The public key system has two accompanying data, the public key and private key. The private key is used to securely create an electronic signature (or decrypt a message). The key is held strictly in the security containment of the Signature Creation Device (SCD), where the signature is created. This is referred to as public key cryptography and public key signature.

The public key is used to verify signature (or encrypt messages), and it can be published to everyone (as the name “Public key” imply). In this way, anyone can verify the public key signature.

Both an applet on SIM (or eSIM) card and a smartphone application (App) can be used as a platform to create public key signatures. The key question today is “Can we trust the private key containment”?

Both platforms have had their share of annoying implementation mistakes. For example, there have been incidents where an external party has been able to easily determine or calculate the private key. Moreover, there have also been incidents where an outsider has been able to execute unauthorized commands on the platform.

These incidents are bugs only when they are found and reported. Is there such a thing as bug-free software which can guarantee that there will be no bugs in the future? Alternatively, we can ask how to fix or limit the possible harm that can be caused by a bug.

Let’s try to compare how security bugs are dealt with on these three platforms.

Smartphone Apps

The App and/or smartphone vendor may publish software bug fixes.

  • Pros
    • Notification services can push new software versions quite fast and easily.
  • Cons
    • Smartphones generally do not receive fixes for system software after few (2 to 4) years after the model was introduced to market. This means that devices become more vulnerable the older they get.
    • Coupled with the ease of increasing vulnerability exploits on smartphones, the risk of such exploitation of is high.

Embedded SIM (eSIM)

The eSIM is an integral component of the phone. The eSIM has good security controls which can be used to limit bug effects.

  • Pros
    • Remote update of eSIM applets can be done easily.
    • eSIM technology is based on well known smart card technology
  • Cons
    • Remote update of eSIM firmware is not supported
    • Replacing the eSIM is not supported

SIM card

The SIM card is proven, and has good security controls which can be used to limit bug effects

  • Pros
    • Bug effects can usually be restricted remotely
    • SIM can be replaced on phone regardless of the phone device age and maintenance.
    • Replacement cases are extremely rare and comparable costs are low.
    • Works also on cheapest feature phone that can not run any games / apps.
    • All phones tend to get the user interface correctly so that no malware can intercept the user interaction.
  • Cons
    • Cumbersome to replace or fix large number of cards (but a lot cheaper than replacing phones!)
    • Replacement means new SIM for affected subscribers, re-registration of every PKI users
    • The user interface is very old style and primitive looking.

A high-end smart phone from a known vendor may be good when the phone model is less than three years old. However, nowadays, the trend is people are keeping their phones for longer, with fewer people interested or can afford to spend 800 euro on a phone every other year.

Similarly, budget smartphones manufacturers tend to save on everything possible. Low cost phones require low cost components, low cost manufacturing and logistics. For example, the security firmware required for secure containment of the private key such as the TEE is most likely the first expensive part to be dropped. Also, these phones or their firmware are generally made in countries which encourage installing backdoors in the devices to call home services for unspecified reasons.

So what are the most important factors that needs to be considered when deciding a secure public key solution for citizens? Based on our experience of smart phone markets, we can say that even though smartphone technology have developed a lot during the last ten years, their security has only been developed over the past few years.

All this means that there will be a significant amount of low cost phones. Security is as good as the weakest link. Therefore, we claim that the most important factors are:

  1. Price of the private key containment.
  2. Security of the private key containment. (This is often much later in priority list. Security does not sell.)
  3. Easy maintenance of the private key containment.

This highlights that security is coming distant second after the price in the market place.

The cheapest devices for private key containment are discrete SIM cards. If SIM security has an implementation bug, like ROCA of 2017, restricting incident and replacing cards is an option that does not require replacing all of user’s phones or contacting multiple vendors or restricting the service.

What about TEE on smart phones? Could it solve the cost, security and maintainability challenge?

Today, many TEE implementations have not been used a lot. They may still have poorly implemented cipher primitives in them. ARM TEE implementations have been seen to use vulnerable security primitives allowing exfiltration of the security containment content, (with the most recent being: CVE-2018-11976 Qualcom TEE implementation).

These require vendor supplied patches, but on Android they stop being distributed after a few years nearly universally independent of the vendor. Even Apple have had this type of mistake in iPhones in the past, but even old iPhone models still get latest and greatest iOS releases with all patches.

Patch availability is subject to many things, mostly “that is so old a product, we don’t deliver new updates on it anymore”.  But also commerce political insanity (see Huawei link.)

Similarly, rooting the phone overrides the inherent security of the TEE. Phone rooting (installing firmware that lets one to bypass security mechanisms) is easily able to replace the TEE implementation with a new one that does not report phone being rooted, and will serve internal key material just fine.

What if we could do all this security within the App itself? Today most of the identity Apps rely on Android/IOS keystorage and security libraries. Only a few Apps implement their own algorithms, fingerprint readers or face-recognition mechanisms. And when they do it, they require high-end smart phone platforms. Therefore, Apps themselves cannot solve the cost, security and maintainability challenge

The eSIM is a promising secure technology that does not suffer from the vulnerabilities of Smartphone App implementation, albeit it is only available on expensive high-end smartphones. With reduced chip costs, eSIMs along with SIMs promise the highest PKI security today and in the near future.


  1. Example of a SIM card firmware bug:
    • This is an example where application chose to use “faster” library to generate keys, but key quality turned out to be seriously weak.
    • On an eSIM a replacement application using correctly behaving certified standard library would have solved the issue.
  2. Externally snoop secret key out of microcontroller type security containment:
    • Note: This is not on a SIM-card hardware with snooping countermeasures on it. However this illustriates how easy it is to extract secret data out of poorly implemented security containment.
  3. Qualcom TEE implementation bug letting all security containment data to be extracted:
  4. Samsung TEE: Cache-Attacks on the ARM TrustZone implementations of AES-256 and AES-256-GCM via GPU-based analysis
  5. An Android Vulnerability Went Unfixed for Over Five Years:
  6. Enisa; Privacy and data protection in mobile applications; Nov 2017
  7. “Huawei Smartphones Will Lose Google Android Software And Services, Reports Claim”

Methics moved office

Methics moved on 2nd of May 2019.

The address for the new office is:

Methics Oy
Lars Sonckin Kaari 14
02600 Espoo

Tagged with: ,

The Strongest in Finland Certificate

Methics Oy has received the Strongest in Finland Platinum certificate from Finnish credit rating company Suomen Asiakastieto Oy.

Methics registers “mss” URI Scheme

IANA today registered provisional URI scheme “mss” published by Methics. The “mss” scheme defines the URI for SignatureProfiles used 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 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 chould 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 define existing Signature Profile URIs, these URIs are conveniently short and easy to understand.

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: , , ,