4

what's the current use of java cards? The documentation is either really old or really sparse. After googling for some time, this is my perceived idea:

  • eID: signing document hash with private key, issued by central authority (government) - signing legal documents

  • unique ID - identification (of person) by ID, protected by PIN and secured by TLS

  • java connected edition web application - I've not been able to find any documentation for the usage of this, except template applications in IDEs. Why are APDU's still used when there's this layer available? Is the application for this non-existent?

Despite all the new functionalities, I see they're only used as identification for a central repository/provider? And the TLS is used to secure communication between the card and backend server?

Thanks.

aeolus
  • 53
  • 4

1 Answers1

5

SIM cards are usually Java Cards, banking cards from Mastercard and Visa are usually Java card, and so are many others. ePassports can be build using Java Card. There are secure elements within readers that are Java Card. Driver licenses, driver licenses, digital tachograph cards, access control cards, cards holding PGP keys, etc. etc. etc..

There are billions of Java Cards, and Java Card is the only reason why Java was claimed by Sun to be on 3 billion devices (and note that they will probably not count Android as that officially is not Java). Currently the JCF (Java Card Forum) is also pushing Java Card forward as secure / programmable element to be used in IoT devices.

eID can be and usually is used more than for just signing documents. It is mainly used for authentication. It may also be used just to verify specific attributes of a person such as his / her age. And it can of course be used to decrypt information if an encryption key pair is present.

So no, there are many more things that Java Card can be used for.

As for the connected edition: it requires highly expensive hardware (smart cards are products that rely on high volume where every cent matters). Furthermore, a lot of protocols are specified using APDU's: you cannot just replace that with HTTPS to the smart card without respecifying the protocols.

ISO/IEC 7816-4 is a horrible standard - if you can call it that - but it currently is the only broadly accepted one. Java Card RMI has not caught on either; I don't see why the connected edition will suddenly change that.

Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263