Our Online Store have the new products: RFID antenna board. Currently it can work with JC10M24R and JCOP4 card chips.
Compared with normal cards, the antenna board module has a smaller size and fixed holes, which is easy to integrate in the IOT(Internet Of Things) project.

How to implement an secure applet

JavaCard Applet Development Related Questions and Answers.
Erisaron
Posts: 15
Joined: Wed Dec 02, 2015 1:23 am
Points :64
Contact:

How to implement an secure applet

Post by Erisaron » Mon Feb 13, 2017 4:20 am

At present, we are concerned more about the usage of javacard api and other technical points. As for the overall design of a safe applet, there is little discussion.

The currently known security policies are as follows:
     1. APDU encryption and decryption
     2. APDU + MAC
     3. Internal and External certification
     4. PIN verification
     5. operational data MAC calculation verification

Is there a comprehensive security policy, or a reference implementation? thanks.

tay00000
Posts: 161
Joined: Tue Sep 27, 2016 10:58 am
Points :2324
Contact:

Re: How to implement an secure applet

Post by tay00000 » Mon Feb 13, 2017 11:24 pm

Security policy depends on what organisation and standards you or your organisation dictates to use. One example is FIPS-201 requirements for PIN codes and authentication for US Govt PIV programs but as far as it is known, there are no commonly known agreed basic guidelines on smart card security that is binding across multiple industries and nations yet.

One standard that many are following is the FIPS-201 for PIV and ID smart cards if one is interested in making some sort of ID applet of sorts. For passports, there is the ICAO standard for ePassport under the ICAO 9303 specification. For the banks, there is EMV and such and multiple banks and nation's financial standards may implement something a little different from each other base on each nation's regulation.

The general guideline I personally adopt is:
1.) Create a generic CLA, INS, P1, P2, LC and wrap the actual INS, P1, P2, LC into the body to protect whoever tapping on the line from knowing the true intentions of the APDU packet. Also, I would pad all plaintext message until they reach maximum packet length before encrypting so that all traffic on the line or over contactless looks almost the same and makes it much more difficult for attackers to decide which message is important enough to spend time attacking.

2.) A MAC (o.e. HMAC-SHA256) would best be calculated over the encrypted packet with or without the APDU headers. Depending on your scheme and organisational requirements.

3.) I assume Internal and External certification to do with some corporate PKI for chip cards ? If that's the case, there is two route where a corporate HSM is used to securely inject private keys and even card PINs into the card. Another route is the card has a hard-coded organisational root public key (inside the applet codes if possible) and generates a card keypair during personalization phase and submits it's public certificate to the corporate root CA. The corporate root CA (best to have a HSM to store corporate signing keys) attest the card's public certificate and issues an attestation certificate to the card. Whichever route is takem, before personalization of the card, the cards are to be physically secured with strong OPSEC practices (i.e. keeping cards in safes with CCTV cameras and physical security guards) until the cards are provisioned and certificates issued.

4.) PIN verification should be done within the chip itself. If there is a need to verify to an external resource (i.e. a Internet portal), it is best not to send the card's PIN in plain or encrypted form (many banking portals I see are doing this mistake) but instead use the chip's PKI certificate to do attestation. The reason is simply if the card's PIN is used not only to login to the chip card but also to login to some web portal, it opens more surface for attacks and weakens security significantly and also threatens the security of the chip card.

5.) The standard HMAC-SHA256 should be used as this particular HMAC function is supported in US NIST FIPS programs and other internationally recognized standards. Note that other MACs that uses block ciphers (i.e. DES MAC or AES MAC) relies on the strength of the cipher and DES-based MAC should be obsolete as soon as possible. Up till now, HMAC-SHA256 is one of the most widely recognized keyed MAC methods and is a highly recommended algorithm to use and it brings the benefits of complying with US NIST FIPS programs if the applets are intended to reach a wider audience ranging from Government agencies to financial bodies and other corporations.

User avatar
UNKNwYSHSA
Posts: 630
Joined: Thu May 21, 2015 4:05 am
Points :3053
Contact:

Re: How to implement an secure applet

Post by UNKNwYSHSA » Tue Feb 14, 2017 9:34 pm

Follow the specifications mentioned by tay000000, example ICAO, EMV, ...
sense and simplicity

Erisaron
Posts: 15
Joined: Wed Dec 02, 2015 1:23 am
Points :64
Contact:

Re: How to implement an secure applet

Post by Erisaron » Wed Feb 15, 2017 1:56 am

Thank you very much for all the help. It has enlightened me a lot.

Post Reply Previous topicNext topic

Who is online

Users browsing this forum: No registered users and 41 guests

JavaCard OS : Disclaimer