Tuesday, August 26, 2008

To connect or not is the question ...

With Java Card 3.0 a connected card is becoming a reality than a dream.

The connected version of the cards Virtual Machine will be close to the J2ME CLDC configuration but with some major differences. The traditional Java Card (Classic) will exist and evolve in parallel.





However, it comes to mind that probably my credential is better off not being connected to the Internet ... A token which is in my pocket is fairly secure. A token is unconnected is a safer heaven for my credential information than a connected device.

I love the idea of making my credential available to the world ... that would be cool. However, with connecting comes the fear of destruction and non-availability attacks.

Well, well ... the days of cards with firewall are probably not too far. Java Card 3.0 will be the enabler for such securely connected device, which is smart enough to protect it from outside threats like worms and viruses.

I felt the same when I got my first contactless card ... and then world came up with the idea of adding controls through the use of paper and plastic RF opaque sleeves ...

Sunday, January 20, 2008

AES for Java Card

AES for Java Card 2.2.x

With the acceptance of Rijndael's algorithm for higher strength symmetric key cryptography, AES was introduced in Java Card 2.2.x as an addition to the open specifications that has fairly extensive API for cryptography. The AES API was introduced in line with existing and widely used SPI for DES. This API is now widely used in various identity management applications. The author was instrumental in designing and finalizing it, and getting it through for its introduction in Java Card 2.2.x






AES was needed for different purposes, however the first application to adapt the technology was the upcoming (now prevalent) 3G networks. It was desired that to be used for different purpose to maintain the privacy on the wireless network. The API is explained better here in this presentation. The observation was that the AES standard implementation turned out to be more efficient than that of DES. At the specified block size AES was also observed to be more efficient on smartcards than DES.
---

Wednesday, January 02, 2008

Contact or (Contact)less

FIPS 201 -- Card Biometric Data and Privacy Concerns

FIPS 201 has defined the access to cardholder's biometric data as "Upon CHV Verification". This implies each time a physical or a logical access system accesses the card's biometric data, the card holder will need to enter the user PIN. Additionally, according to the PIV specifications, the biometric template which are stored in the credentials can be retrieved only from contact side. The biometric template could be more than just fingerprint like condensed facial image, iris scans etc.

The approach to add verification of PIN before use of biometric template may be a overkill and hinder some of the easiest access control systems especially for physical access. A medium confidence access system may verify the biometrics of the holder either through data on the card or through data stored in the back-end system like the biometric server. A secure and valid credential whose signature can be verified is supposed to be an authentic credential.

Some of my thoughts on the subject which lingered more than a week in my mind are noted below. Comments on the items below will be much appreciated.

  • Don't cardholders' leave their fingerprint(s) on numerous objects which they touch like keyboards, mousepads, door knobs etc. etc. ?? Bad guys can easily pick up the fingerprints and make a dummy finger and card which be used to fool the PACS. The intruders can easily make the dummy and use it to falsely open the door. The PIN entry and its verification by the card, may not even be asked by the PACS.
  • The privacy concerns about misuse of biometrics are probably valid for authentication of the card holder. A remote authentication of the user using biometrics only shouldn't be allowed by the logical access system. A PIN + biometric (2-factor authentication) could also be weak authentication mechanism if the PIN is verified only by the card. For this two factor authentication scenario, the PIN match MUST be performed by the secure server.

  • Verification of identity doesn't require same level of security as authentication ... Authentication is proving who you claim is really who you are ... Verification is identifying someone whom I already know and have means to verify since I trust some data in the secure part of the system. Typically, for full authentication a PKI is involved.


  • CHUID can be read over air interface ... Why restrict minutia, if CHUID is all available to be read without card holders verification? Well, the argument that I have heard is that CHUID can be protected by keeping the card in a RF insulatoted jacket. Well then can't we apply the same arugment in favor of the biometric data? As we all know, PIV defines some low assurance verification methods which uses only CHUID, this may be as insecure as letting the biometric template be read over the contactless interface.


  • What happens in case the reader is slot - neither contact nor contactless? A slot reader is a good alternative to contact/contactless interfaces. Its widely used in applications where high throughput is required. A good example of such a device is a public telephone and the prepaid smart card reader which is part of the installed public phone.

  • Well, just like other biometrics, the bad guys can easily capture the card holder's other biometrics like the facial image and iris image. The cardholder may not even notice such a theft. With video cameras becoming increasingly popular these days at public places, this is becoming more and more easier.


  • Even with the PIN verification, a system design is needed to make dispel the privacy concerns and fears about the use of biometrics with the card. Some dialog, between the card holder, the requestor's authenticity and log of permissions granted by the card holder for the use of the biometrics are steps in right direction ....

---

Monday, September 10, 2007

125 kHz Vs 13.56 MHz

Why migrate from 125 kHz to 13.56 MHz for Identity systems?

The present generation identity systems are migrating from 125 kHz towards 13.56 MHz. Why is there this technology shifts towards higher frequency? Even the new contactless payment systems are using the 13.56 MHz and not the age old and tested 125 kHz frequency band ... Besides being universally open and available for scientific use there are some technical reasons, which has been gathered below. The 13.56 MHz is better suited for the following reasons.

13.56 MHz Advantages Over 125 kHz


13.56 MHz is available for higher data rate and higher available bandwidth as compared to 125 kHz

Smaller component values which are easier to integrate and manufacture. As the frequency goes high the values of capacitance and inductance required to generate the resonant frequency goes low, thus making it easier to manufacture.

Higher tolerance to electrical noise which is noticed to be stronger in the MHz range especially in industrial environments. The higher frequency means more energy can be transferred with less and therefore, the immunity to the stray and system noises increase.

Higher tolerance to electrical noise which is noticed to be stronger in the MHz range especially in industrial environments. The higher frequency means more energy can be transferred with less and therefore, the immunity to the stray and system noises increase.

13.56 MHz Disadvantages Over 125 kHz

13.56 MHz is limited to short range inductive coupling systems, some of the higher frequency systems like the microwave RFID systems have better coupling but are harder to build.

Monday, June 04, 2007

Type A Vs. Type B

Type A Vs Type B Communication

PIV cards and reader communicate through RF which is also used to power the PIV cards. When there are many smart cards in the field, the tags need to negotiate the communication with reader. The algorithm used to negotiate communication between reader and card is known as anti-collision. Anti-collision can be performed either using the time space, wherein a time slot is allocated to the card talking to the reader or the data communication space wherein the collision is detected by the corrupted data due to the collision.

The differences between the two types of communications and method of data transfer is listed here. Its important to note that different types of communication not only bring in the differences in the way data is modulated to the carrier but also the way power is transferred to the smart cards.


---