Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Encryption Australia Security

Australian PLAID Crypto, ISO Conspiracies, and German Tanks 62

Posted by Soulskill from the get-what-you-pay-for dept.
New submitter Gaglia writes: PLAID, the Australian 'unbreakable' smart card identification protocol has been recently analyzed in this scientific paper (disclaimer: I am one of the authors, and this is a personal statement.)

Technically, the protocol is a disaster. In addition to many questionable design choices, we found ways for tracing user identities and recover card access capabilities. The attacks are efficient (few seconds on 'home' hardware in some cases), and involve funny techniques such as RSA moduli fingerprinting and... German tanks. See this entry on Matt Green's crypto blog for a pleasant-to-read explanation.

But the story behind PLAID's standardization is possibly even more disturbing. PLAID was pushed into ISO with a so-called "fast track" procedure. Technical loopholes made it possible to cut off from any discussion the ISO groups responsible for crypto and security analysis. Concerns from tech-savvy experts in the other national panels were dismissed or ignored. We contacted ISO and CERT Australia before going public with our paper, but all we got was a questionable and somewhat irate response (PDF) by PLAID's project editor (our reply here). Despite every possible evidence of bad design, PLAID is now approved as ISO standard, and is coming to you very soon inside security products which will advertise non-existing privacy capabilities.

The detailed story of PLAID in the paper is worth a read, and casts many doubts on the efficacy of the most important standardizing body in the world. It is interesting to see how a "cryptography" product can be approved at ISO without undergoing any real security scrutiny.

On a related note, the enthusiastic comments to PLAID's design made by a few readers in the old Slashdot story reminds us as a cautionary tale that you need cryptographers to assess the security of cryptography. Quoting Bruce Schneier: amateurs produce amateur cryptography.
This discussion has been archived. No new comments can be posted.

Australian PLAID Crypto, ISO Conspiracies, and German Tanks More

Australian PLAID Crypto, ISO Conspiracies, and German Tanks

Comments Filter:

  • PLAID must be fast! (Score:5, Funny)

    by greenwow ( 3635575 ) on Wednesday October 28, 2015 @12:45PM (#50818039)

    Even faster than LUDICROUS.

  • ISO corruption (Score:5, Insightful)

    by Anonymous Coward on Wednesday October 28, 2015 @01:03PM (#50818203)

    The detailed story of PLAID in the paper is worth a read, and casts many doubts on the efficacy of the most important standardizing body in the world. It is interesting to see how a "cryptography" product can be approved at ISO without undergoing any real security scrutiny.

    Not really surprising given the Microsoft OOXML standard controversy a few years ago. I suppose the ISO could always have been susceptible to influence peddling in the past, but the OOXML thing was the first time I, and a lot of others, became aware of it.

    • Like OOXML, it is a good example of how politics can override the standards process. In the case of PLAID, they needed something that complied to an international standard. They already had their own homebrew system, so they got that made an international standard, a case of the tail wagging the dog.

      ISO 24727 (aka '747, due to its elephantine size) is another example of this, and in the same general area as LUDICROUS... uhh, PLAID. The whole thing is, and I'm not making this up, over six thousand pages l

  • Now we know that anything with PLAID insecurity (ISO/IEC 25185-1) should be automatically removed from consideration. I suspect as many new products will come out with this as there will be with MD5 and SHA-1 over the next few years. It's a dead standard before it was even published.

    • I would be surprised if there are any products out there using PLAID, given that it is still flagged as "under development". If it's been shot down at this stage, then no harm has been done, and basically the standards process is functioning as it should.

      • Re: (Score:1)

        by Gr8Apes ( 679165 )
        It should have been shot down. However, my point was that it's already dead. No one would create a product with this standard, as it is meaningless. Imagine the negative PR about your product if you implemented this standard for anything other than a government product, and even then.

  • ISO JTC1/SC27 is meeting right now in Jaipur India. I'm one of the US delegates, but screw ups leading to no visa meant I didn't go.

    I imagine they might be having some discussions in the corridors about this.

  • Response to criticism (Score:5, Interesting)

    by myrdos2 ( 989497 ) on Wednesday October 28, 2015 @01:09PM (#50818269)

    Here's the meat of the "questionable and somewhat irate" response:

    The following are factual and editorial errors in the document:

    1. Abstract – States that for AS 5185-2010 "we show that the privacy properties of PLAID are significantly weaker than claimed" but in fact the report shows that the privacy properties of PLAID are unbroken by the attack and in fact unbreakable by the attack. The report actually shows that the "ID Leakage" properties of the protocol (as defined in AS 5185-2010) could be better implemented in the 2010 version of the reference implementation by implementing the fake "ShillKey" better - see further discussion in section 6.2.

    2. Abstract – states that it will be ...." reporting a number of undesirable cryptographic features of the protocol" This is however unargued and not actualised. The reference appears to logically means section 5.3 of the Unpicking PLAID paper however, as shown in section 7 of this discussion these are either not claims of the protocol or are not shown to be weaknesses by any argument presented by the Researchers - see further discussion in section 7.

    3. History in Introduction is not 100% correct – the Public Consultation process included additional workshops and stages – see section 4 "History" above

    4. P3, Last paragraph, the words "added for privacy reasons" is incorrect, the ShillKey was added to delay and distract an atacker, privacy was never an issue and is not stated as a design requirement.

    5. P4, last paragraph, P5 first paragraph – Not clear what point is being made – OPACITY is a completely different protocol based on Eliptic Curve technology. Last sentence seems to mix this Paper on PLAID up with a completely seperate report on OPACITY.

    6. P3 2nd last paragraph the Researchers state "Even though the encryption key in RSA is usually public, in PLAID it is kept secret to enhance privacy". This is an incorrect representation of PLAID, the reason for both keys being kept secret is in fact to prevent any leakage to an attacker of the AES diversification seed in order to enhance security. Note that PLAID is not a PKI, and the use of public and private key concepts is not relevant, ALL keys are secured in (preferably) hardware crypto devices.

    I'm no crypto expert - can anyone explain to me why these points aren't valid? Especially points 1 and 4.

    • Re:Response to criticism (Score:5, Informative)

      by suutar ( 1860506 ) on Wednesday October 28, 2015 @01:22PM (#50818385)

      1 and 4 together make me think that the author is saying that shill is completely irrelevant to privacy and the rest of plaid is just as private as advertised. The problem is that while shill may have been intended as a bolt-on to distract and slow attackers, it apparently also can be used to do the tracking that the rest of plaid was designed to avoid. The author claims that's not a problem because it wasn't designed to be private, but the end effect seems to be that the card is more trackable than intended. A better implementation of the shillkey could help with this, but is not required by the standard nor implemented by the reference, so how many commodity hardware makers are going to bother?

    • Re:Response to criticism (Score:5, Insightful)

      by Anonymous Coward on Wednesday October 28, 2015 @01:50PM (#50818679)

      Part of the argument the PLAID designers are making boils down to "well it's theoretically possible to implement it securely even if the standard doesn't warn you about that risk, nobody does it right, and even the reference implementation got it wrong".

      For examples of how well that works out in real life, see:

      * WiFi WPS pins - just search the web for "WiFi WPS pin attack" - most WiFi routers were vulnerable
      * DNS source port randomisation - http://www.kb.cert.org/vuls/id/800113 - most DNS resolvers were vulnerable
      * PKCS#1 signature validation - https://www.imperialviolet.org/2014/09/26/pkcs1.html - most browsers were vulnerable
      * Many others

    • Re: (Score:1)

      by Anonymous Coward

      Your question is legit, but I'll try to explain why these points are invalid (as far as I get it, i'm just a PhD crypto student)

      First of all one has to understand that cryptography is a very paranoid thing: you always have to assume the worst case scenario. But most of the work is actually to figure out *what* the worst-case scenario is. This is called "defining a security model", and it is something non--cryptographers are VERY bad at doing.

      For example, in this plaid scenario, consider this security model:

      • Re: (Score:3)

        by plover ( 150551 )

        I think the most dangerous aspect is that this protocol has no way to revoke keys. That means "break once, profit everywhere."

        If one terminal is successfully compromised and its private key is lost, every card with a lost key is subject to the compromise of all traffic, past, present, and future. That means if you are using it to guard an access door to a venereal disease clinic in some small town in the outback, it may contain the private key granting access to a central building guarding all national heal

      • Re: (Score:1)

        by Gaglia ( 4311287 )

        Author of submission here. All correct, moreover:

        3) As we state in our response:

        "While the analyses by Watanabe [Wat13] and Sakurada [Sak13] in some sense confirm authentication
        and key secrecy properties of PLAID under the assumption of idealized cryptographic primitives, we—as
        already discussed in our paper—disagree with considering them as “cryptographic proofs” as the project
        editor’s report does. In particular, these analyses do not consider privacy aspects."

        5) We never meant

  • Shocking (Score:3)

    by ThatsNotPudding ( 1045640 ) on Wednesday October 28, 2015 @01:59PM (#50818761)
    This is so unlike the trustworthy NSA and their rock-solid, shenanigan-free encryption wares.
  • Entertainment value set to 2048 bits.

  • amateur hour at the crypto factory.... (Score:5, Insightful)

    by xeno ( 2667 ) on Wednesday October 28, 2015 @03:01PM (#50819253)

    It's irrelevant to the core logic of the issue, but misspellings and grammar errors are a pretty good indicator of the quality of a piece of work.
    A "mute" item would be "(1) refraining from making sound or (2) silent" -- one that does not make an actual audible sound.
    A "moot" item is one that is "(1) of no importance or (2) merely hypothetical."
    There are many other errors that seem to indicate this whole document was whipped up in a hurry by a pissed off individual without review, but the high-school-level error "mute point" sticks out like a sore thumb.

    Seeing this kind of minor but highly-visible mistake in the headings and TOC of a formal document... does not lend credibility to the whole.

    • Re: (Score:1)

      by Gaglia ( 4311287 )

      Author of submission here. I agree with you xeno, but this is just my personal view and does not necessarily reflect the one of all the people involved. In our paper we used "moot" when intended, and "mute" when quoting from the PLAID editor's report, as it is the usual good practice. But, disclaimer: as a non-native English speaker, I cannot be sure whether "mute" could also be used in some Australian slang with the intended meaning. Thanks for pointing that out!

  • Evolving protocol more than ten years old (Score:3)

    by Stonefish ( 210962 ) on Wednesday October 28, 2015 @06:24PM (#50820799)

    Hi, as someone who also worked for a company which was working for Centrelink at the time (Not involved in PLAID) I have to admit that I admire the development of PLAID because the commercial products available were rubbish and "Security agencies" such as NSA and DSD were not helpful in this regard. A significant gap in the way that smart-cards which were being used for access control such as building security worked was found and an attempt was made to re-mediate this.
    Protocols evolve over time to either become better or reveal the fact that they are fundamentally flawed. SSL was not written by cryptographic experts it was created by Netscape and it has evolved over time to secure a significant percentage of Internet transactions. PLAID exists because all of the available security products in this space were fundamentally broken and PLAID was an attempted to fix this problem. During the time since this protocol was created I've watch the various debacles with a number of propriety commercial smart card products used in public transport. I would hope that PLAID will evolve over time with the assistance of interested parties to be an open protocol which provides a solution in this problem space.
    One criticism of this appears to be that a department which spends billions of dollars on ICT infrastructure should engage in the development of a product when there is an identified gap identified in the market. The spend in total was in the hundred thousand dollars so in reality the project was done on a shoestring is it's not surprising that there are flaws.

    • SSL isn't a good example of a protocol done right by amateurs.

      The fact that SSL didn't generate a barrage of FUD from certain three-letter agencies is the surest sign that SSL sucks butt.

      Ref: https://weakdh.org/imperfect-f... [weakdh.org]

      (oh, and I find it hilarious that the above is in an https link).

    • Re: (Score:2)

      by AHuxley ( 892839 )
      re "such as NSA and DSD were not helpful in this regard"
      The main mission in Australia is to look after US, UK collect it all shared sites running 24/7 out in Asia, Pacific and a huge list of 'other' nations.
      Staff that are left over from that task are working on Australian only services to duplicate the above so if the US or UK ever shut Australia out again, Australia still has its own full access to every network in the region. With full real time translation, plain text under Australian command structu

  • I'm the author of the original submission. There was a mistake in the story, as we never contacted AusCERT [auscert.org.au], but CERT Australia [cert.gov.au] instead. The similarity of the names was a bit unfortunate. I apologize for this error. Could some moderator please edit the submission? Thank you!

Slashdot Top Deals

"If it ain't broke, don't fix it." - Bert Lantz

Close