I came across a website containing very useful information for smart card projects: http://www.smartcardbasics.com/
It is an excellent starting point and reference source for any project leader since it contains - among other things - overviews of standards (ISO7816, FIPS120, EMV etc), smart card system planning, and security (systems, infosec, cryptography, and more).
Monday, 19 April 2010
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.
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.
Monday, 28 December 2009
RFID Zapper
Easy, cheap, portable way to fry RFID tags: Rfiddler
Original article here.
"The gun was fabricated using a Nerf N-Strike Recon CS-6, with a 0.6 kilojoule camera flash driving a 50-turn copper spool."
It seems simple enough.
Implications:
1) Easy theft - "disappear" tagged items.
2) Easy impersonation - no interference from existing tags.
Applications:
Commercialisation on the grey market for use by crime syndicates: firstly, stealing from RFID-automated warehouses and dispatch centres; secondly, re-routing shipped items; thirdly, changing tariffs on shipped items; fourthly, clearing shipping containers illegally; fifthly, passport/ID disabling.
Moral of the story: beware taking the human out of the decision loop because you never know when they will become necessary again.
Original article here.
"The gun was fabricated using a Nerf N-Strike Recon CS-6, with a 0.6 kilojoule camera flash driving a 50-turn copper spool."
It seems simple enough.
Implications:
1) Easy theft - "disappear" tagged items.
2) Easy impersonation - no interference from existing tags.
Applications:
Commercialisation on the grey market for use by crime syndicates: firstly, stealing from RFID-automated warehouses and dispatch centres; secondly, re-routing shipped items; thirdly, changing tariffs on shipped items; fourthly, clearing shipping containers illegally; fifthly, passport/ID disabling.
Moral of the story: beware taking the human out of the decision loop because you never know when they will become necessary again.
Thursday, 10 December 2009
JCOP performance
Interesting and relevant to real-world implementation: JCOP performance differs between revisions.
Update on Java Card GDIs
For what it's worth, here are the most popular options currently available to Java Card developers:
- eclipse-jcde 0.1: Free plugin for Eclipse wrapping the Sun Java Card Development Kit. Use with Eclipse 3.5 (JDK1.5 or later) and JCDK 2.2.2 Classic , Java Card 2.2.2, GlobalPlatform 2.2 (including JC Export file 1.3). The GlobalPlatform API may also be useful for manually or programatically communicating with a smart card. If your target is Java Card 3.0, use Netbeans and JCDK3.0.1 instead.
Note: a useful off-card interface for Java is Global Platform for Java SmartCardIO.
- Netbeans IDE 6.7: Free; use with Sun JCDK 3.0.1 Connected Edition.
- JCOP Tools 3.1.2: Free devkit from NXP (proprietary, requires an NDA). Use with Eclipse 3.3 (JDK1.4.2 or 1.5 only). Target OS is JCOP 2.2 (?). Includes libraries from GlobalPlatform 2.1.1, Java Card 2.2.1. Not all ECC functions (Java Card) are represented in the simulator.
- JCOP Tools 3.2.8: Latest version; free from NXP (proprietary, requires an NDA). Use with Eclipse 3.5 (JDK1.6). Target OS is JCOP 2.4.1 (supporting Java Card 2.2.2 and GlobalPlatform 2.1.1), and possibly JCOP 2.4.2 (Java Card 3.0, GlobalPlatform 2.2). Simulator includes most of the Java Card functionality.
- Giesecke&Devrient Sm@rtCafe Professional Toolkit 2.0: free demo. Supports Java Card 2.2.1 and GlobalPlatform 2.1.1; target OS is G&D Sm@rtCafe 3.x.
Monday, 24 August 2009
More on GPShell commands
It can be hard to know the AID of the applet instance to select with the GPShell select command, and the accompanying readme really doesn't enlighten the novice developer.
I find that the best way to get the necessary info is to open a secure channel to the Card Manager, and then do a get_status instruction. For example:
Note that the select command requires hex values: ASCII characters don't seem to be supported (with or without single or double quotation marks), and an error is not thrown; instead some default domain or package on the card is selected (APDU 00A4040000). This can lead to extreme frustration on the part of the developer when all subsequent test APDU's return the status word 6D00 (unknown INS value).
I find that the best way to get the necessary info is to open a secure channel to the Card Manager, and then do a get_status instruction. For example:
select -AID a000000003000000This returns all selectable applet instances on the card.
mode_211
enable_trace
establish_context
card_connect
open_sc -security 1 -keyind 0 -keyver 0 -mac_key 404142434445464748494a4b4c4d4e4f -enc_key 404142434445464748494a4b4c4d4e4f
get_status -element 40
Note that the select command requires hex values: ASCII characters don't seem to be supported (with or without single or double quotation marks), and an error is not thrown; instead some default domain or package on the card is selected (APDU 00A4040000). This can lead to extreme frustration on the part of the developer when all subsequent test APDU's return the status word 6D00 (unknown INS value).
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:
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):
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.
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 4CThe 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".
--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 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 2where "-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.
Subscribe to:
Posts (Atom)
