Is there a chance smartcards have a backdoor? (was Re: Any future for the Crypto Stick?)

[Mark Schneider]

Am 08.12.2013 11:51, schrieb Paul R. Ramer:
> Peter Lebbing <peter at digitalbrains.com> wrote:
>> We're debating the risk that a card is backdoored. If there is such a
>> risk, that
>> risk still exists if we allow for the possibility that manufacturers
>> try to do
>> what you say. They're not mutually exclusive; how come you infer that I
>> assume
>> that the manufacturer would not do the opposite?
> It was not my intent to make it seem that I had made any insinuations on your part.  It was more that I wanted to express an alternate possibility rather than the nefarious one that was being discussed.
>
> It seemed that the only scenario involving pressure or coercion on the part of the U.S. being discussed was one of compliance by the company rather than a range of possibilities.  Events in life do not always happen neatly and predictably.  If we are going to discuss outcomes, we need to talk about more than one.
Looking backwards (history) if there was a possibility to build in a 
backdoor such one
always had happened and had been exploited.
It applied and still applies for "most" of commercial IT software and 
hardware vendors
and even such OSS projects focused on securiry like openBSD (in the past).

Smart cards are good only for a certain level of privacy to keep rather 
primitive ciriminals away.

As long everyone is not able to audit the source code of firmware or 
operating systems
(in particular closed source software products) there are a lot of other 
possibilities to steal your secrets.

I didn't follow the history of the CryptoStick until now but I would 
like to add my "few cents" somewhere later.

An idea would be not to trust anyone and to create so called linux live 
images yourself.
(saving them on a read-only medium and booting from it into live mode).
Example and some description how to do it:
http://rsync.it-infrastrukturen.org/banque-live/
http://git.it-infrastrukturen.org/banque-live.git

Due to my limited time resources all existing .iso images there are 
currently NOT up to date (8 months old).
It is for me a time intensive challenge to patch gnupg 2.0 or the much 
more interesting 2.1
to support longer keys and create .deb packages with all dependencies.
(like RSA 15k .. even they are not inside "secure" standards  .. from my 
"paranoid" point of view)

A little security is not real security. There always can be backdoors in 
the firmware (BIOS, closed source drivers etc).

Kind regards, Mark

-- 
ms at it-infrastrukturen.org

http://rsync.it-infrastrukturen.org