Showing posts with label GlobalPlatform. Show all posts
Showing posts with label GlobalPlatform. Show all posts

Tuesday, 18 February 2014

Return of the son of GPJ

The descendant of the venerable GPJ has been announced. Its easy-to-use command-line is sure to be popular with developers, and it also offers a simplified interface for key provisioning and diversification. Code: https://github.com/martinpaljak/GlobalPlatformPro

Monday, 10 October 2011

OPAL Released

The University of Limoges has released an open-source client implementation of the Global Platform specifications named OPAL. Eric Vetillard posted an interesting opinion on OPAL and the status quo of open-source software for smart cards.

Wednesday, 26 May 2010

OpenSC Project

New resource found, OpenSC Project :
OpenSC provides a set of libraries and utilities to work with smart cards. Its main focus is on cards that support cryptographic operations, and facilitate their use in security applications such as authentication, mail encryption and digital signatures. OpenSC implements the PKCS#11 API so applications supporting this API (such as Mozilla Firefox and Thunderbird) can use it. On the card OpenSC implements the PKCS#15 standard and aims to be compatible with every software/card that does so, too.
In the Java section there are useful tips and links about JNI for PKCS#11, javax.smartcardio, PKCS#15 and GlobalPlatform.

Friday, 19 March 2010

OSS jcManager

I came across this useful open source tool for managing JCOP cards:
http://www.brokenmill.com/2010/03/java-secure-card-manager/


From the project homepage:

Motivation:
Some time ago there was a JCOP tools plugin for the eclipse IDE developed by IBM labs in Zurich but it is no longer available.


Features:
- low-level implementation according to GobalPlatform Card Specification
- supports both SCP01 and SCP02 card protocols
- open source
- cross-platform
- display detailed debug information to be able to understand the complex low-level operations – derivations, encryptions, padding, etc
- uses the musclecard pcsc java implementation for the low-level communication with readers/cards. Also, it is fully compatible with the IBM JCOP implementation - if you do have the offcard.jar library from IBM it will also seamlessly work with it.
- works with the majority of card readers (pcsc compatible). Tested with Schlumberger, Omnikey, etc

It's early days for this project but it looks very promising.

Thursday, 10 December 2009

Update on Java Card GDIs

For what it's worth, here are the most popular options currently available to Java Card developers:
If there are more, please notify me.

Monday, 24 August 2009

Card Recognition Data

To get the GPShell open_sc command to work with an applet instance (not the Security Domain), we must ensure that the correct Secure Channel Protocol implementation number is specified.

This number can be retrieved from the Card Recognition Data TLV fields via the OpenPlatform get-data command on tag 0x66 (send APDU 80CA0066) after selecting the Card Manager. For example, with the Nokia 6131 NFC phone, the command returns:
66 4C
--73 4A
----06 07 2A864886FC6B 01
--60 0C
----06 0A 2A864886FC6B 02 02 01 01
--63 09
----06 07 2A864886FC6B 03
--64 0B
----06 09 2A864886FC6B 04 02 55
--65 0B
----06 09 2B8510864864020103
--66 0C
--06 0A 2B060104012A026E0102
9000
The response is formatted into TLV fields according to GP 2.1.1 Section F.2 or GP 2.2 Section H.2, "Structure of Card Recognition Data".

The field at tag 64 (offset 50 in the unformatted string) aka "application tag - GP OID 04" has scp=0x2 (SCP02), i=0x55=85 (scpimpl). Note that this is different from the default i=0x15!

The field at tag 60 aka "application tag - GP OID 02" specifies the GlobalPlatform version, namely GP2v2.1.1 (compare with value in given by ATR and OpenPlatform get-cplc command). This gives a clue as to the Java Card version that can be expected (2.2.1).

The GPShell command to open a secure channel (MAC and ENC) to an applet in the Secure Domain would then be (after selecting the applet):
open_sc -security 3 -keyind FF -keyver 0 -mac_key 404142434445464748494a4b4c4d4e4f -enc_key 404142434445464748494a4b4c4d4e4f -scpimpl 85 -scp 2
where "-scpimpl 85" specifies the decimal value of the SCP number.

Note: according to the GP spec. H.3, the GP select command on the Security Domain may return TLV values which - if present - override the Card Recognition Data described previously. What exactly this implies I still have to figure out ...


****
Update: I discovered that the COS on the IC in the Nokia is G&D SmartCafe Expert 3.1 which is indeed Java Card 2.2.1 compliant. See this post.

Thursday, 25 June 2009

Smart Card SCP02

GlobalPlatform Secure Channel Protocol 2 (GP SCP02) allows secure communication with an applet. It is documented as Appendix E in the GP Card Specification 2.1.1

GP card-side classes (org.globalplatform.GPSystem and org.globalplatform.SecureChannel, included in JCOP Tools gp211.jar or in GP Card Specification) make it easy to process, wrap and unwrap secured APDUs.

Card managers supporting SCP02 include JCOP Tools and GPShell.

(No info on terminal-side classes for SCP02 yet. Watch this space.)

SCP03 has been specified by GP middle of 2007 as part of Card Specification 2.2 but it's not clear if there are any implementations which support this yet.

Tips for managing sessions and applets:
  • Remember that have only 10 tries to authenticate to a JCOP card manager. Successfully authenticating will reset its internal counter. After 10 failures the card manager will be locked and cannot be unlocked, although the applets on the card will remain usable. This is different than the situation where the card itself is in GP state CARD_LOCKED, which is reversible.
    Using the wrong key-set is the most common mistake people make. Confirm that you are using the right key-set: read the tutorials on-line and contact your vendor if you don't have supporting documentation for the card.
    JCOP Tools get-cplc prints the production info for the card (aka ISD), which you can send to the card vendor (or google!) to get the key-set. If you are already authenticated to the card and want to confirm the default key-set number, use init-update: the response APDU has the key-set number you used to authenticate in the 11th byte, and the SCP version in the 12th byte. (Refer to GP2.1.1 Appendix D4.1 and D4.2 for init-update and ext-auth commands). Remember that using init-update when not authenticated counts as authentication failure, which will use up one of your tries! First reset the ISD failure counter by authenticating successfully, then continue experimenting.
  • SCP02 requires key-type CBC (valid key types are DES, DES-ECB, DES-CBC, RSA-PRIV, RSA-PUB, RSA-CRT, DSA-PRIV, or DSA-PUB). If you specified SCP02 ENC+MAC by using JCOP Tools command ext-auth enc, JCOP Tools will automatically set key type to CBC even if you set key type for example DES-ECB.
  • The card has several life-cycle states, usually READY or SECURED (the latter requiring external authentication level C-MAC at least). Refer to GP2.1.1 Section 5.1.

Wednesday, 24 June 2009