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.
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
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com