Talking about Cryptodevices... which one?

[Matthias-Christian Ott]

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