Activation protocol for tracking devices

[Santiago Aguiar]

I'm afraid this email will probably will be a) flamed away (because it's 
not from a cryptographer, but forced to do crypto-things, and I do know 
your opinion about this matter...) b) ignored (same reason!). I'm 
sending it anyway because any kind of feedback would be welcomed ;), and 
the situation is, in my opinion, dire...

As I wrote in my last email, in Brazil they are devising a protocol to 
activate tracking/blocking devices to be installed from factory in 
*every* vehicle, starting progressively from august 2009. The idea is 
that a service operator (SO) can activate a device to work with it, by 
first asking a centralized agency, the DENATRAN (department of transit), 
that must authorize the activation request. Once activated, the device 
keeps in that state until the SO deactivates it or until DENATRAN 
reconfigures the device SIM card remotely to change it IMSI to a special 
network operated by DENATRAN.

We are trying to suggest options for this activation protocol, and for 
our current one I have some questions I would like to confirm with 
knowledgeable people like you ;):

* 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.
* 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?

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

 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...). The SO is connected thru an 
authenticated connection to DENATRAN (ie. vpn). Reply attacks could be 
possible, we are proposing to include and additional incremental 4 byte 
numbers to use as nonce. In the activation protocol H can be much 
stronger than the one used later. I'm aware that the way of applying the 
hash function must be carefully studied, but at this point we need a 
reasonable idea to discuss over (I would love if this message gets 
bashed to the ground ;)). Message encryption has been outright discarded 
by the working groups.

I'm not asking for anyone here to actually provide a solution (it would 
be stupid to do so), it's just that by looking at how things are 
progressing at Brazil, if nothing comes out, things will just be ignored 
and the implemented solution will probably be quite catastrophic.... At 
this time, in Brazil there are thousands of tracking companies, each 
with their own protocols and devices, but this regulation will impose a 
government dictated monoculture that creates a very fertile ground for 
massive exploits.

Thanks!

Regards,

Santiago.

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