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.
The App and/or smartphone vendor may publish software bug fixes.
- Notification services can push new software versions quite fast and easily.
- 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.
- Remote update of eSIM applets can be done easily.
- eSIM technology is based on well known smart card technology
- Remote update of eSIM firmware is not supported
- Replacing the eSIM is not supported
The SIM card is proven, and has good security controls which can be used to limit bug effects
- 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.
- 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:
- Price of the private key containment.
- Security of the private key containment. (This is often much later in priority list. Security does not sell.)
- 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.
- 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.
- 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.
- Qualcom TEE implementation bug letting all security containment data to be extracted:
- Samsung TEE: Cache-Attacks on the ARM TrustZone implementations of AES-256 and AES-256-GCM via GPU-based analysis
- An Android Vulnerability Went Unfixed for Over Five Years:
- Enisa; Privacy and data protection in mobile applications; Nov 2017
- “Huawei Smartphones Will Lose Google Android Software And Services, Reports Claim”
- Apparently phones already on consumer hands continue access to Google Play, only new devices are blocked.