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.
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.
Related
How can one define a customized security domain on a smart card? Suppose that I have a GSM sim card in my mobile (I don't know operator key set to modify my sim)! Am I correct if I want to install a customized security domain on the same sim card in order to have an independent island on the sim to manage few applets of mine (not the operator)?
What properties should a security domain have? Is that possible to write one or use any pre-written online? Is that possible to install it on sim card without knowing the key set?
First of all, Java Card is a programming language to write applets that run on smartcards with a Java Card RE/VM. Global Platform is a standard for installation and management of smartcard applications, that includes the concept of Security Domains. Many smartcards out there combine both (although that is not necessary) and I assume this is your usecase as well.
There are two types of security domains, the (highest,top-level) Issuer Security Domain and Supplementary Security Domains. Firstly, if you not know the keys of the Issuer Security Domain, you cannot add another Security Domain or any other applets. The ISD is always preinstalled and usually there is a SSD load package on the card, that can be used to install and instantiate a SSD. The Security Domain is just another applet with the Security Domain privilege, but it has the functionality to load/install/manage applets and interact with the JCRE/VM directly. Technically you might be able to add the Security Domain privilege to your self-written applet.
All the information can be found in the freely available Global Platform specification and its needed to read through the pages if you want to dig deeper.
Is it generally possible to access a shareable interface of an applet installed in a different Security Domain in a card compliant to both Java Card and Global Platform specifications?
If this is not possible, is there another way of invoking applications in another Security Domain, potentially by manually communicating via Secure Channels?
From the JavaCard Runtime Environment spec, Shareable Interfaces (6.2.4) :
Shareable interfaces are a feature in the Java Card API to enable applet interaction. A shareable interface defines a set of shared interface methods. These interface
methods can be invoked from one context even if the object implementing them is
owned by an applet in another context.
The applet firewall of the Java Card world divides between contexts(6.1.2), the ShareableInterfaceObject is spefically designed to enable interaction between contexts that would otherwise be forbidden.
The concept of Security Domains originates from the Global Platform specifications and is not present in the JavaCard specification. Searching the term in the JavaCard documentation will actually yield no results. As these things don't have anything in common, there should not be a problem with your setup.
I'd like to provision a JavaCard so that it only allows the installation of applets that are signed by a certain key. I am not sure whether this signature is part of the cap file format. I can already install a cap file from an Android device via code taken from GlobalPlatformPro. The GlobalPlatformPro README (https://github.com/martinpaljak/GlobalPlatformPro/blob/master/README.md) mentions application signing. But I am not sure this is the way to accomplish what I need to do. I am not even sure this is possible at all.
How do I need to prepare a card to only allow installation of signed cap files?
How do I create such a cap file?
I can already lock a card with a certain key, and then this key is needed to install any cap file. But this would mean that I need to distribute the key with the cap files, so it can be installed. That is not an option as it would compromise the key.
You should read the Global Platform Specification, all information is given there.
Points to look out for that should match your requirements:
Mandated DAP Verification
Delegated Management Tokens
You will still probably need to check that your Java Card supports the given feature(at least Tokens are optional for card manufacturers) and you will need a terminal software that supports this feature(which might be difficult, as it is not very commonly used).
In Java Card, is it generally possible for new applications to be installed from within the context of an existing application on the card, for example by sending the new code via an application-defined messaging format and then creating a new application instance using some card manager API?
Or is this only possible externally using the corresponding APDUs?
If this is something not covered by the Java Card and/or the GlobalPlatform specification, can it be done using vendor-specific methods?
Theoretically this could be possible for normal Java Cards, given that:
you can install an applet with the Security Domain privilege (support for this is optional);
the Security Domain has the option to perform INSTALL [for Load] (support for this is optional);
the applet can receive and alter the APDU buffer before the Security Domain functionality is invoked (using SecureChannel.processSecurity) - as processSecurity should itself retrieve the command data according to specifications this is more unlikely then you might first think;
the applet has been given access to the keys to recalculate the MAC (these are keys are kept hidden from the Applet itself), assuming that the card is in GP_SECURE mode.
In this case you could convert your own APDU's into specific APDU's that comply with the GP specifications and simply call SecureChannel.processSecurity to get them processed.
Practically I don't think above will ever be the case, but you never know. You'd explicitly go around the security protocols defined for the card implementation, so I'm pretty sure you'd be asked very explicit questions by anybody auditing the solution.
Now if you just want to install applets through your own security domain then this is explicitly covered by Global Platform. You'd just check the manuals of the product if security domains and INSTALL [for Load] is supported and you're good to go.
As vojta has already indicated, there is no API for handing over INSTALL [for Load] commands, so programmatically you'd be stuck.
An incredibly stupid way to do it would be to program your own VM and install it as an applet. Probably not practical in 99.999% of the cases. It would still only be reachable as the VM itself of course, it would not be given its own Application ID (AID) by the card.
No, it is not possible.
You cannot send APDUs from your applet to Card Manager applet, which is what you need to install a new applet. Card Manager also doesn't provide any Shareable interface for this task (usually).
The only way is to send APDUs via the terminal, but it is not what you probably want. This way would be easy: your applet would need to hold the complete binary of the new installed applet and keys of the Card Manager.
However!
You can install an applet by another applet on SIM card using so called proactive commands, see this SO answer. Provided the device allows it, you can send PERFORM CARD APDU command from the first SIM slot to the second SIM slot and install a new applet this way. Then you could use this new applet on SIM2 to install another applet back on SIM1.
Moreover, you could send OTA commands using proactive commands and install a new applet instance remotely. I tried this a few years ago with a very simple pair of applets and a test SIM card and it worked.
Theoretically, it might be possible to implement a Java Card applet which will spread itself over the mobile network provided you have all the necessary keys. However, this is closely related to the Java Card quine, which is not solved as far as I know.
I am new to javacard programming.While working with owner pin in my javacard application, I referred that "PIN interface which is in javacard framework package does not make any assumptions about where the data for the PIN value comparison is stored".
And I want to know the following,
Can I get the exact location where my owner pin is stored? If I can how to do that? How to export my updated owner pin?
I have an applet of my javacard application. Now how can I load & install into my javacard.I know there are tools available and come with the smartcard itself. But I want to install without tool and only through apdu commands. Is there any procedure to do that? If so how to do that?
Sorry, you cannot retrieve the OwnerPIN, probably because of security reasons. You will have to implement the PIN interface yourself if you want to do that, but there are about 8 pitfalls in the implementation regarding side channel attacks and such. If you can't think of about 8 attacks, don't go there. Generally, retrieving the PIN as data is not what you should want.
Of course there is a procedure to do that: create your own GlobalPlatform API - you might want to look at open source examples though, such as gjp.
As an extreme hack, you could store the PIN in as the value of a secret key object (which are generally well protected).
Regarding the installation of applets I have a good and bad news for you:
The general process of command for installing is standardized by Global Platform, however that refers only to those commands you send to the Cardmanager-Applet.
However AFAIK there is no vendor independent standard of the Cardmanager-AID. Additionally you have to authenticate yourself to the Cardmanager applet before you can use it. On developer cards this is usually a simple key like 404142434445464748494a4b4c4d4e4f (hex) as used for example by JCOP cards for the first DES key.
Additionally this authentication key can be changed by the card owner. Therefore on non-developer cards you don't have access to the Cardmanager.