Sorry about the improper threading; I’ve switched off digest mode, hopefully this will help.
> On Mar 15, 2015, at 9:06 AM, MFPA wrote: > Pretty much any system *could* be compromised. Should > we say all bets are off because there is a possibility the > system might be compromised? I may have phrased my point inartfully. I think the goal here is to minimize the harm done in the case of compromise. An attacker substituting a message and convincing your smart card to sign it is bad, but it’s not as bad as leaking secret key material that the attacker can use at will. > We are told that smartcard design precludes copying the > key material without physically destroying the card and > applying some pretty heavy-duty forensics. But do we > *know* this to be true, or is it just collective wishful thinking? The smart card runs code based on a specification. [1] The specification does not allow exporting a secret key, and we write code that adheres to that specification. We know that much to be true. You do have to trust the firmware and the operating system on the smart card, but that’s made easier by the fact that chips in these cards [2] and the operating system [3] are certified to be secure based on international standards, and are widely deployed in sensitive areas like access control, payments and telephone SIM cards. I think it’s encouraging, in a perverse way, to hear that when GCHQ sought to compromise SIM card encryption keys [4], they had to resort to spying on the employees generating them. If the smart card firmware or operating system were backdoored, they would not have had to go to such lengths. > PIN-entry being on the Android device you are using > presumably means that an attacker who managed to > evesdrop your NFC connection would be able to record > the signal containing the PIN. Yes, this is a concern. It requires physical proximity of a few meters and some kind of specialized equipment, but it’s theoretically possible. > Which they may then be able to re-send, hypothetically > allowing them to continue signing or decrypting so long > as your card was within range of their equipment. How > is this type of threat mitigated against in your current > specification? With NFC the main mitigation is physical rather than cryptographic in nature. Since the card has no battery, the attacker would have to supply an RF field sufficient for powering up the chip to perform the math and transmit a response. In theory, that maxes out at 10 centimeters; in practice, it’s about half that. You can negate this attack with an RF blocking sleeve, which I’ll almost certainly be adding to the kit after this conversation. I admit that this may not be sufficient for some people’s security needs, but my sense is that more people are vulnerable to passphrase-sniffing malware than they are to someone sneaking very close to them with an evil device. The former attack scales quite easily; the latter attack does not — and again, the evil device attack still won't expose secret key material. Thank you for your critical responses, by the way; I appreciate the chance to be transparent about the challenges involved. [1]: http://www.g10code.com/docs/openpgp-card-2.0.pdf [2]: http://www.nxp.com/documents/data_sheet/P5CX012_02X_40_73_80_144_FAM_SDS.pdf [3]: https://www.commoncriteriaportal.org/files/ppfiles/ANSSI-CC-profil_PP-2010-03en.pdf [4]: https://firstlook.org/theintercept/2015/02/19/great-sim-heist/ -- Joey Castillo www.joeycastillo.com _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
