On 01/24/15 16:57, Andreas Schwier wrote: > On 01/24/2015 12:05 AM, Matthias-Christian Ott wrote: >> The same is true for the OpenPGP smart card or for almost any other >> smart card available on the market. They could all contain a secret key >> escrow mechanism and some probably do. Proprietary smart cards are hard >> to audit and verify and are easy targets for backdoors and bugdoors. > Can you provide any evidence for that claim or is this just paranoia ? > > Working in the smart card industry for close to 30 years now, I've never > come across an incident where a smart card was deliberately backdoor'ed.
This is just paranoia and pure speculation for which I have no evidence. I just replied to an email that speculated that an intelligence agency has an agreement with a card reader manufacturer to leave security vulnerabilities unpatched. If you assume this, you also have to assume that the proprietary OpenPGP card is also subject to such an agreement. I also remarked that it would be technically feasible to deliberately insert a key escrow mechanism or some other backdoor or bugdoor into a smartcard. In the current global threat model we have to assume that there are forces with enough power and resources to pursue anything that is technically feasible. Whether you assume this threat model is up to you and subject to your level of paranoia. I don't think that such discussion belongs on this mailing list but I felt that I had to intervene to stop portraying the OpenPGP card as a secure solution. Any secure software has to be Free Software. Otherwise it is very difficult to verify its security. I think we could go on and on about threat models, security usability and so on. Such a discussion would lead nowhere and is highly speculative. In fact a smartcard with backdoor would probably be more secure than the an average Windows computer or an unpatched Android phone because it's more difficult to exploit. However, I think that it is not healthy and dangerous to look at computer security from such perspective and apply security economics and so on because it is speculative and you compare people to money. > Most smart cards used today in security sensitive mass applications like > banking cards, signature cards, national id cards or passports must be > independently evaluated and certified under the Common Criteria scheme. EJBCA is also Common Criteria EAL4+ certified but still has bugs so such certification is not a guarantee but merely an indicator. In a public presentation an EJBCA developer also mentioned that the certification organization only looked at the software at a conceptual level and never audited the source code. So such certification does not prevent backdoors or bugdoors and is essentially worthless if you assume such threat model. With your experience you probably know more about Common Criteria certification. I just repeated what happened in the case of EJBCA. >From my experience as a software developer and Java Card in particular I'm confident that it is very difficult if not impossible to develop a secure implementation a specification of the complexity level of GlobalPlatform or similar even if you use formal verification. There will always be attacks that you did not anticipate. Without many eyes looking at the source code you will never know if your software is secure. So without repeating a discussion that is being repeating over and over again about whether Free Software is more secure or applying a perspective on security that only considers something to be secure or insecure without somethin in between, I think it everyone on this mailing list would agree that it is important for security that software is Free Software and that proprietary smartcards are problematic. > I can not image a way to introduce a backdoor without being detected > during evaluation or in the secure delivery procedure. I can hardly > imagine a smart card manufacturer or evaluator that has to take > liability for a security product with a deliberately introduced backdoor. I can imagine this. What do we do now? There is no mechanism to verify this. If the smartcard manufacturer uses deterministic builds and provided access to the source code, you could verify that to the extent that you feel assured that the source code does not contain backdoors and that the software on the smartcard is indeed the software that you think it is. > I agree, that we've seen bad implementations in smart cards. We've even > seen certified products, that generated not so random numbers (Even > though this was the classical case of a developer trying to be smarter > than the user guidance allowed him to be). A recent example would be the Taiwanese national ID cards. I could not find the exact model and certificate for the card but I'm sure that they were somehow certified and they are indeed used in "security sensitive mass applications" without being "secure". I'm certain that the weak random number generator would have been found if the source code had been available and there had been a competition with reasonable prices to comprise the cards before they were rolled out. > Still smart cards have a case: They link the private key to a protective > and controllable piece of hardware. I can disconnect the card from the > PC and I can rest assured that no copies of the key exist and the key > can not be misused (Unless someone steals card and PIN). That is an > important security attribute that no software keys can provide for - at > some point in time the software key must be somewhere in memory. As already mentioned, under a certain threat model a successful attack only needs two signatures: one for the revocation certificate and one to sign the key of the attacker. And again I don't think we can discuss the security or effectiveness of smartcards without a concrete thread model because without that you can always argue that something is secure or insecure if you assume X, Y and Z and the discussion leads nowhere. So if you want to make this discussion fact-based and continue on, propose a threat model that satisfies the needs of the person asking the original question and we can carry on the discussion. - Matthias-Christian _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
