Activation protocol for tracking devices

[Jerry Leichter]

On Feb 27, 2009, at 2:13 PM, Santiago Aguiar wrote:
> * Is there any standard cryptographic hash function with an output  
> of about 64 bits? It's OK for our scenario if finding a preimage for  
> a particular signature takes 5 days. Not if it takes 5 minutes.
Not specifically, but you can simply take the first 64 bits from a  
larger cryptographically secure hash function.  If the nature of your  
usage is that an attack requires finding a preimage to an externally  
specified hash value, 64 bits is reasonably secure.  (If being able to  
find a pair of values with the same hash value, 64 bits is way too  
short.)

> * Suppose a cryptographically secure random number is stored on the  
> device from factory, could I use the output of a block cipher  
> applied to this number as a way to generate new random numbers  
> (since the output from the cipher should not be distinguishable from  
> random data)? In case yes, could I do this with a hash instead of a  
> cipher?
Both of these techniques have been used.  If you want a simple  
security argument for the block cipher case, use the pre-stored random  
number as the key and encrypt 0, 1, 2, and so on.  If some can use  
this output to get the key; or if given encryptions up to n, they can  
guess the encryption at n+1, then the cipher could not be used in  
counter mode (since what you are getting is exactly the counter-mode  
encryption of an all-0-bits message).  Obviously, you'll have to store  
the counter across boots, since otherwise you repeat values.

With a hash, you need to be a bit fancier since, in and of itself, the  
hash has no secret information.  This can be done, but it would be  
trickier; I'd go with the block cipher.

Note that there are published algorithms - even part of FIPS standards  
- that do exactly what you need:  Take a single random seed and safely  
stretch it into a large number of random values.  The ones in the  
standards - and perhaps most of the ones out there - are old and  
probably not up to contemporary standards.

> For those interested, this is what we are proposing at the time:
>
> Every TCU (the device) comes pre-installed from factory with a Kt  
> known to the device and DENATRAN.
>
> SO-> TCU (device): sends a SMS with GPRS connection information  
> (apn, user, pass, server IPs/ports). The mechanism so that this  
> first SMS is not a big issue have been, reasonably, covered.
> TCU->SO: challenge
> SO->DENATRAN: challenge, SO_id
> DENATRAN->SO: H(Kt, challenge, SO_id), Kc=H(Kt, challenge)
> SO->TCU: H(Kt, challenge, SO_id), SO_id
You're trying to produce a keyed hash function (or MAC) from a non- 
keyed hash function.  Just pre-pending the secret key is not  
necessarily secure.  I'd suggest using HMAC (with Kt the key, of  
course).

> From that point, Kc is stored in SO and TCU, and every message  
> interchanged between the SO and TCU goes signed with Kc (for this we  
> need a H with max. 64 bits output...).
Signed?  How?  I don't understand the 64-bit limitation.  I'm not sure  
a 64-bit signing key is sufficient these days.
                                                         -- Jerry

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com