Re: Erasing an OTP file on a SD card.

From: Joris Dobbelsteen (none.of_at_your.business)
Date: 07/29/04 

Date: Thu, 29 Jul 2004 13:22:43 +0200

> > Are you aware of someone looking over your shoulder, or worse, hearing
every
> > word you say?
> > Did you know that I break into your house and copy your SD card?
>
> If you leave your encryption hardware available, this is a problem,
> but our system erases the SDCard after each conversation, then the
> SDCard will need to be stoled and analysed in a more difficult way.
> If you have problems to get the SDCard with you, i think you don't
> want security, in this case the best way to deal with this situation
> is: Don't use a secure phone.

You forget to consider the part before you are having the conversation. At
this point in time the SDCard is vulnerable.

I don't whether you know the RSA SecurID. This device runs for a finite
period of time and generated a 'pseudo-random' value, as function of the
time. In this case you:
a) must have the device
b) must know a PIN.
The device itself cannot be opened (without rendering it useless) and you
can (probably) not use a electron microscope on the device. So the data
inside the device cannot be copied and there is no way feasable way of
computing the next value that will appear on the display. When the battery
dies, you just throw away the device, because its useless.
In the SDCard case, its vulnerable to an obvious attack, copying the data
before its used.

The situation would be improved when:
The device storing the OTP itself ensures that it can be read only once.

> We have an option to our clients securing their symmetric keys in our
> system, we can encrypt the symmetric keys using Rijndael 256 bits key
> and 256 bits block lenght, and we have an option to the user avoid

Shouldn't this be standard?

> dictionary attacks (changing the SHA-256 password hash before
> encryption).
>
> > Did you know people are stealing entire ATMs, so they probably have
little
> > problem taking your safe away (do you actually have one)?
> > Security is more than using ciphers to secure the actual
communication...
> >
> I think that walking with an ATM machine over your shoulders is a very
> hard task, but i don't build an ATM machine. Our OTP is in a SDCard.
> If you want security, you must take care, i can't solve all your
> problems, you only have security if you, at least, have your hardware
> with you.

IHMO you don't implement a OTP unless
a) Your transaction need to be absolutely secure and normal cryptography
doesn't work good enough
b) You must provide an absolute guarentee the OTP key data is protected.

As you are pointing out, you want OTP because of its security, but you don't
solve the security issues the OTP makes you vulnerable to. These
vulnerabilities can be solved in a good other way.

A scheme with a trusted third party with the money and resources to secure
their systems appropriately (certificate authoritity like Verisign) and
conventional ciphers would, for normal users, have less issues.
Assume here that the public key is stored in a secure manner, just like the
OTP data. However, where you need the SDCard for the OTP, you can use a more
secure device for the public key.

> You are writing using arrogant expressions, i work hard to get a
> decent life, and i need money to survive. We can do a decent job and
> be payed. I think i answered your previous questions in a polited way
> (i tryed).
> You don't know me to talk in this way, please take care when writing
> to decent people. If you want to discuss technical questions, you will
> be answered.

Yes, I know, I have a bad habbit of sometimes putting things in a annoying
(or bad) way.
Please accept my appologies. Hopefully I did it better this time.

I'm currently developing a sensor for pendulum clocks to measure the
'frequency' of the pendulum. The chip runs at 18.432 MHz and every cycle I
can detect the pendulum passing. So my accuracy would be:
1 / (18.432 * 10^6) * (60*60*24) sec/day ==> 0.00468 sec/day deviation.
The fact is however, that the deviation is still 4 sec/day and the deviation
cannot get any less (without making the device way too expensive for the
market I'm targetting).
So there would be absolutely no means to use this kind of resolution for the
timer, except that its easier (and smaller) to implement this way.
Now I probably would put on the site that it uses a 18.432 MHz timer,
because big numbers look better at first glance.

This device contains some cryptography in order to ensure duplication is
difficult. I don't want hobbyists to do my job. Even so, with enough effort
you can recreate it, so the concept might seem very strange to start with
and probably is. I believe that it provides me with what it is designed for,
no copying.

- Joris

Relevant Pages

  • Re: Erasing an OTP file on a SD card.
    ... why do not allow our clients to have OTP ... > The security have a price, we have clients asking for OTP. ... you can be sure taht the algorithm is provably unbreakable ... Can i prove that it will be reasonably secure under any ...
    (sci.crypt)
  • Re: [Full-disclosure] Defeating Citi-Bank Virtual Keyboard Protection
    ... >>Costly for the bank but very effective security for the customer ... >poland promised a hand on session breaking OTP tokens. ... secure them that exists today will be thought to be old-school and ...
    (Full-Disclosure)
  • Re: Erasing an OTP file on a SD card.
    ... why do not allow our clients to have OTP ... >> The security have a price, we have clients asking for OTP. ... Can i prove that it will be reasonably secure under any ...
    (sci.crypt)
  • Re: research into modern computer-based one-time pad implementations?
    ... > secure electronic message traffic, ... Computers are not particularly appropriate for implementing OTP. ... secure destruction of keying material as soon as it is used. ... your security degrades from "provably unbreakable" to "how good is the ...
    (sci.crypt)
  • Re: Erasing an OTP file on a SD card.
    ... I implemented One Time Pad under AES 256 bits CBC ... In our system you can't use OTP alone. ... secure than other systems, but in the worst case it has no advantage ...
    (sci.crypt)