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.
Related
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.
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 trying to install an applet which uses security classes (Cipher, RandomData and MessageDigest), but always get an 6F50 error when trying to install it. The package is loaded correctly but the applet cannot be instantiated. I am allocating all objects in the
constructor and the algorithms are supported by the card (at least according to the datasheet). If I comment out all security classes references, the applet loads and installs properly. I've tried allocating byte[] and Object's and it works, so this is not a space related problem (64K card with nothing else on it). I am using the SIM Alliance Loader v2 to load the applet. 'Regular' (non-crypto and STK) applets work fine.
The card supports Java Card 2.1.1 and a subset of Global Platform 2.1.1. Specs are here: http://shop.shadytel.com/sim_datasheet.pdf
Any ideas as to what the problem might be?
It's hard to tell what the problem is as the card returns a proprietary status word that it normally should not return. The 6Fxx error codes are used for unknown errors in the ISO/IEC 7816-4 standards. The value 50 is therefore proprietary to the smart card implementation. Contact the vendor.
The datasheet shows us a very limited Java Card platform, it only shows support for the following cryptographic algorithms:
DES and TDEA (triple DES)
secure and pseudo random
SHA-1
So if you go outside of these specifications you should expect a status word denoting an error. Normally you would expect 6A80 though, indicating something is wrong within the command data. The fact that you get an error while instantiating the applet shows that the code is accepted, but that instantiating or initializing one of the cryptographic algorithms fails.
If you have a good debugging environment (as good as a must for Java Card development), then you should be able to step through the Java Card static install method and applet constructor.