Locking/unlocking a smartcard & security implications

3
votes

I have started to develop applets for smartcards using javacard. When an applet is compiled it must be loaded to the javacard through a secure protocol defined in the Global Platform specification (https://globalplatform.org/wp-content/uploads/2018/05/GPC_CardSpecification_v2.3.1_PublicRelease_CC.pdf).

In particular, loading the applet on the card requires to know cryptographic keys that are used to setup a secure channel between the host computer and the smartcard. Blank cards are typically provided with default keys such as "404142434445464748494A4B4C4D4E4F". To 'lock' the card and ensure that it cannot be tampered, these keys must be changed to something known only by the issuer.

My question is the following: What is the risks associated with issuing cards using the default test keys?

Here is a list of threats that I could think of:

  • A user can remove the applet and reuse the card for another purpose
  • A malicious software could uninstall the applet (denial of service)
  • A malicious software could remove the applet and install a backdoored one instead to steal user credentials in future usage.

Are there any other threats? In particular, is it possible to recover sensitive data (e.g. cryptographic keys) stored in an applet already installed on the card?

I would like to understand the exact security implications of using a smartcard with the default keys for the secure channel.

1
securityappletsmartcardjavacardglobalplatform
Strange question, given how easy it is to avoid the scenario by changing the keys; given that then any applet might be installed I see tons of threats, stealing other applets data is not among them, since these should be private. – guidot
@guidot indeed, a smartcard should always be locked, but if the applet code is open and any user can load it (and omit to lock the card), the goal is to have a clear understanding of the security impact for the user. – Bau

1 Answers

2
votes

The data of the applet should be protected by the "firewall" that is implemented according to the Java Card Runtime Specification (JCRE), chapter 6: "Applet Isolation and Object Sharing":

The Java Card technology-based firewall (Java Card firewall) provides protection against the most frequently anticipated security concern: developer mistakes and design oversights that might allow sensitive data to be “leaked” to another applet. An applet may be able to obtain an object reference from a publicly accessible location. However, if the object is owned by an applet protected by its own firewall, the requesting applet must satisfy certain access rules before it can use the reference to access the object.

The firewall also provides protection against incorrect code. If incorrect code is loaded onto a card, the firewall still protects objects from being accessed by this code.

To do allow sharing the sharing class would have to implement the javacard.framework.Shareable interface (6.2.6 Shareable Interface Details).

Beware though that the attack surface is greatly enhanced if you allow untrusted applets to be run. The likeliness that the security constraints cannot be met will definitely increase. These keys are considered vital to Java Card security and the default keys should always be replaced. If you order larger quantities of cards it is usually possible to replace the default keys with customer specific ones.

Note that at the time of writing the site of Oracle is partly down and I cannot access the documentation. This text is taken from the 3.0.1 specifications that I had stored on my personal computer.