Australian Gov't Offers $560k Cryptographic Protocol For Free

mask.of.sanity writes "Australia's national welfare agency will release its 'unbreakable' AU$560,000 smart card identification protocol for free. The government agency wants other departments and commercial businesses to adopt the Protocol for Lightweight Authentication of ID (PLAID), which withstood three years of design and testing by Australian and American security agencies. The agency has one of Australia's most advanced physical and logical converged security systems: staff can access doors and computers with a single centrally-managed identity card, and user identities can be automatically updated as employees leave, are recruited or move to new departments. PLAID, which will be available soon, is to be used in the agency's incoming fleet of contact-less smartcards that are currently under trial by staff. It will replace existing identity cards that operate on PKI encryption."

Comments

A little more info

[explosivejared]

Here is a briefing on the PLAID 6 protocol with more specifics on the actual algorithms and cryptography in general involved. PDF link if the first one doesn't work for you.

Re:A little more info

[TechyImmigrant]

The protocol looks unremarkable. They pass some entropy and IDs back and forth, using conventional standards based encryption and hash algorithms.

Their problem is keeping the cards secure and they state clearly that they are using commercially available smart cards.

There are secrets in the cards, an RSA private key and an AES master key. The bigger problem is keeping these secrets in the cards and distributing the keys to cards. The PLAID protocol has no bearing on these matters.

Re:A little more info

[swillden]

There are secrets in the cards, an RSA private key and an AES master key. The bigger problem is keeping these secrets in the cards and distributing the keys to cards. The PLAID protocol has no bearing on these matters.

Which is fine, because those problems are easily solved.

Commercially-available smart cards provide a rather high degree of security. Extracting keys from them isn't impossible (nothing is), but it is very difficult and expensive. I design high security systems for a living, and we have no concerns about the security of the cards themselves, because experience shows it's just not an issue.

What we do focus on is the security of the issuance process, because that's where those keys get injected. That problem is also solvable, mainly by performing the key injection in secure facilities using highly secure devices (FIPS 140-2 level 4 certified hardware security modules). It's expensive and complex (from a management and process perspective, not a technical perspective), but a high degree of security is achievable.

The protocol looks unremarkable. They pass some entropy and IDs back and forth, using conventional standards based encryption and hash algorithms.

It is unremarkable, which is one of its most significant strengths. It's just a lighter-weight approach to the problem, one that can be implemented efficiently on current-generation hardware. Previously, PK authentication on smart cards was considered too slow to use for physical access control and other applications where sub-second authentication was required. Faster smart cards coupled with a lightweight authentication protocol mean that PK authentication can be completed reliably in as little as 200 ms. That's fast enough to use it for transit applications.

Re:A little more info

[profplump]

"Completely unnecessary" is a stretch at best -- contact-less interfaces have real benefits. The most obvious is a lack of contamination and corrosion, both on the card and the reader. Another is decreased read times, which allows you to use the cards in more places without increasing the level of annoyance.

Not to mention the "new attack scenarios" do not include simple copying of the card UUID, so radio-based attacks would need to be interactive:
1. Attacker camps out at door with radio equipment
2. Attacker points antenna at employee coming towards door
3. Attacker is able to authenticate to the door as approaching employee

While that's certainly a technically feasible attack it's not terribly practical in execution, even if you setup an out-of-band comm system to isolate the card under attack from the person entering the building.

Plus you really could just issue a foil-lined holder if you were worried about such attacks. Or make authentication two-factor and require the entry of a PIN or somesuch in addition to the card scan.

PLAID 6 Protocol

[Anonymous Coward]

* Uses existing off-the-shelf symmetric and asymmetric crypto algorithms (SHA1, AES 256, RSA 1024, RSA 1984) tied together via the PLAID protocol
- Note - Neither SHA256 nor ECC are used at this time because production cards are either not obtainable from all vendors nor do they achieve the required performance, (in spite of theoretical advantage of ECC)
- Note - RSA 1984 is a trade off between performance and security, and ensuring the transaction fits in one APDU command.
* Fast & simple - less than 1/2 second (400ms) and the Java Card - applet is extremely small (about 4 Kb)
* Not clone-able, re-playable or subject to privacy or identity leakage
* Same protocol can be used for PACS/LACS & contact/contactless
* PIN can be verified when card-not-present by comparing PIN hash
- Saves user having to hold contactless card to reader during typical PKI session
* Mutual authentication Protocol
* Algorithms used are commercially available on virtually all modern smartcards including Java
Card, MULTOS, most SIMs and many proprietary cards
* Algorithms and their selected key lengths have been tested on production cards and devices to ensure speeds are real, not theoretical

* No IP issues - IP was developed solely by the Australian Government by its agency, Centrelink, and will be openly and freely licensed
* Designed to be used either stand-alone or as a bootstrap into other specifications like Australian IMAGE, US PIV, ICAO Passports etc.
* Supports multiple concurrent specs dependant on device request to card
- i.e. Card could supply Weigand number or CHUID or Centrelink CSIC or Passport MRZ etc etc dependant on use case
* Supports multiple (256) key sets dependant on device request to card
- i.e. there might be a "perimeter key set" and a "high security key set" and a "LACS key set" and an "administrative key set" etc etc and the terminal device only requests the one it requires, reducing the possibility of compromise of the others.
- The key sets can be rolled, by loading spare unused key sets (up to 255) in case of compromise (memory is the limitation)
* Optionally provides session keys for higher level specs
* Protocol can be registered and implemented under ISO/IEC 24727-3 and 6, and either used under ISO/IEC 24727or implemented separately

However:
Slightly slower than existing physical access Tag and proprietary solutions (by 0.2 to 0.3 seconds)
- Keys MUST be distributed & managed
* Vendors need to build key management for PLAID into existing or new key management systems. (Centrelink vendor is doing this for LACS)
* PACS using older Weigand technologies need secure SAM devices in the readers
* Newer PACS can utilise back end HSM devices/SAMs on the network or in distribution frames

Re:I laugh ...

[smallfries]

That looks familiar but I can't remember the name, what scheme is it?

The likelihood of breaking it is genuinely 1 in 2^n and can only be broken by brute force attack.

That's not strictly true. Although the discrete log problem is hard it is still a computational assumption. Proving that 2^n is a lower bound would be a significant achievement. This scheme is only "unbreakable" in the sense that RSA is - breaking it requires solving a problem that we suspect, but are unable to prove, is very hard.

Re:Yeah Right...

[swillden]

Given Australian government's views on privacy, I wonder when the back door will be discouvered? Or is looking for it agianst the law?

Look at the protocol. It's so simple that there's virtually no way for a back door to exist.

Implementations can have back doors, of course, but that's a separate issue.

Re:I laugh ...

[smallfries]

I'm not really sure what you mean. Assuming that A and B are roughly the same size, A, B and SQRT(c) will all have about n/2 bits. But I don't see the connection to discrete logs. The scheme assumes that the attacker can't compute Xd,Xs,Yd,Ys. If the attacker observes the D transmitted in steps 5,6 and 7 then he can attempt to invert the exponentiation revealing Xd and Ys.

My head is a bit too hungover to follow through the implications, but Xs is the multiplicative inverse of Ys and so should be unique and can be computed cheaply using Euclid's algorithm. The same holds for Xd and Yd, so if the attacker can solve discrete logs (inverting the modular exponentiation) then he can recover all four of Xd,Xs,Yd and Ys. This then reveals the original D.

In practice solving discrete logs for this type of group is about as hard as factoring. It hasn't been proven to be hard, but nobody has come up with an efficient way of doing it. Either proving a lower bound of O(2^n), or finding a cheap algorithm to solve the problem would be a significant break-through.

The other main problem with the scheme is that it is susceptible to a Man In The Middle attack. If the attacker can intercept and alter the communications between source and destination then he can substitute his own choice of Xd and Yd and reveal D directly. To get around this there needs to be some form of authentication as well as the encryption.
 

Re:Yeah Right...

[swillden]

I wasn't talking about the issuer keys. There are more keys that let you in to other levels of the card hardware. This is not generally publicized and the only reason I know about it is because of how long I have been working in this field. Now this may not be true of all Java Cards but it is for every one I have seen.

Well, I've been working with smart cards in general for over 12 years, and with Javacards ever since they've existed, including having done some work on the JCOP operating system (IBM's implementation of Javacard, now owned by NXP), and I've NEVER heard of keys at a lower level than the CardManager keys.

Which specific cards have you seen this to be true of? And how did you find out? It's certainly not in the documentation of the cards from Gemalto, Oberthur, G&D or NXP.