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.




The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to