I've written my applet and installed on my card. what should I do to prevent further modification or installation of applet on my java card?
I have read that I should change default key set. I tried GPShell but I could not change keys!
I tried jcManager but it could not recognize my readers (acs and REINERSCT)!
how can I finalize my card to deliver user. Can any one tell me finalization steps to make my card safe?
Thanks
Change Authentication Keys:
GPShell and JCManager are really old tools that not supported anymore. Try to use newer tools such as GlobalPlatformPro [Its executable file download link].
Command to change default authentication keys using GPPro:
gp -lock <PutTheNewKeyHere>
And to reverse the above operation(Changing the new key to the default value):
gp -key <TheAboveNewKey> -unlock
More commands described here.
Change Life Cycle of your applet and Security Domain:
To change the life cycle of your card, you can use SET STATUS APDU command:
Examples:
_OP_READY_ To INITIALIZED : 80 F0 P1 07 |Lc| AID
INITIALIZED To SECURED : 80 F0 P1 0F |Lc| AID
P1 = 40 : For Applications (Including SSDs)
P1 = 80 : For ISD
Make your applet the Default Selected applet:
To install your applet as the DEFAULT SELECTED applet, use -default option with the installation command in GPPro:
GP -install <PathToYourCapFile> -default
(if you changed the card manager authentication keys, you need -key option in the command too).
You can also change ATR of the card to make it hard to recognize your card type by its ATR. To change the ATR, you can use SetATRHistBytes() method in Global Platform APIs.
There is no way around changing the Issuer Security Domains keys. Beyond that there are multiple security guidelines to protect your card that are described by the Global Platform specification. To meantion some:
Load FileData Block Hash/Signature (make sure you loaded on card what you actually intended to)
Change Life Cycle of the Card to secured
Change Life Cycle of your applet or finalize your personalization process by any other meaning
Change the Card Manager keys or your ISD or other SDs
Disable the GP Load/Delete command(proprietary)
Disable selection of the Card Manager(proprietary)
Changing the Card Manager keys is the most important and standard one. Diversification might be used.
Try another tool like GP Pro or check all your actions again.
Related
We want to store digital certificates for PDF signing in virtual smart cards. Due to regulatory reasons (FDA, we are developing medical devices), we have to assure that the PIN protecting the certificate has to be (re-)entered again for each document to be signed. The default behavior seems to be that the PIN has to be entered only for the first document during a windows session. Is there any option to configure a "always prompt" policy, like it can be usually done for conventional smart cards?
First check that you are actually relying on the smartcard itself and not a kerberos ticket or something derived liek that, try klist and klist purge.
Check the Base CSP PIN Cache Policy settings here.
Alternatively, you can forcefully remove the PIN from the cache if you are using an CSP with:
CryptSetProvParam(hProv, PP_SIGNATURE_PIN, NULL, 0)
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.
If I write a Java Card applet that emulates one or more protocols of the same ISO standard, is there a way to have the applet "auto selected" by protocols which don't use select, or don't know what to select? Because otherwise I'm not going to bother spending ten to twenty dollars for a test device, and god knows I'd need more than one.
You'd better looked through Global Platform specification first.
When you install your applet, you can set it as the defaultselect applet.
Two ways to do this.
1- Recommend that you download JCIDE-- a Free java card applet development.
Here is how to set the defaultselect applet by a simple operation .
2- There is also a handy tool that can meet your need.
You can download it from here
Hope it helps.
Yes, you can install your applet as "default selected", which is basicaly what you want.
Have a look at Global Platform specification, especially parameters of INSTALL [for install] command. There is one flag in applet privileges you have to set.
If you work with Eclipse JCOP Tools, you will easily set the flag using GUI Applet Install Properties:
Yes.
Javacard Applets are usually always deployed on a smartcard with the underlying Global Platform standard. Global Platform is used to deploy, maintain and manage JavaCard applets. When installing a Java Card applet you can set an option/ flag called defaultselect. Only one applet can have the default selected option. Whenever an ATR/ATS is received the JCRE internally selects the applet with default-select option. Any APDUs incoming are directly handed to the applet unless a select APDU selects another applet registered in the JCRE.
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.