Re: Activation protocol for tracking devices
Santiago Aguiar wrote: 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. This does sound like it introduces novel risks. I would suggest that rather than spending too much energy on the cryptomath, it would make sense to focus energy on the systems issues and the security requirements. 1) Is the system really intended to allow a single government agency to deactivate a car, without permission from the owner of that car? If so, that creates systematic risks that should be examined carefully. Is there any chance of revising the security requirements, so that consent of the owner is required? Good requirements engineering may be able to make as big a difference as any amount of crypto. 2) Strong audit logs would appear to be important. In particular, here are a few ideas. One might require that anytime a car is deactivated, a postcard is sent to the owner of that car letting them know of the deactivation and who authorized it. One could also require that an audit log be kept of every deactivation event and who precisely authorized it, and mandate that the owner of a car has the right to a copy of the audit log for their own car at any point, without delay. 3) You might consider advocating an opt-out policy, where car owners can turn off the functionality that allows deactivation of their car without their permission, and/or turn off the tracking functionality. 4) You might want to ask about what protects the location privacy of car operators. Does this system provide a third party with the power to track the movements of cars around the country? That sounds like a serious privacy risk to me. What controls are there to protect privacy, surveillance, or government abuse of power? 5) I would think that another possible security concern may be social engineering: if DENATRAN has the power and is authorized to deactivate cars, one tempting method to maliciously deactivate someone's car might be to convince DENATRAN to deactivate it. How will that be prevented? What are the procedures that DENATRAN will follow before deactivating a car? Are these required by law or regulation? 6) Are there penalties for inadvertent, incorrect, or unauthorized deactivation of a car? One possibility might be to require that the agency or the business pay a fee to the owner of the car if the owner's car is improperly deactivated. That might then put the onus of securing the infrastructure on the folks who can do something about it. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Activation protocol for tracking devices
David Wagner wrote: This does sound like it introduces novel risks. I would suggest that rather than spending too much energy on the cryptomath, it would make sense to focus energy on the systems issues and the security requirements. Very interesting read. These topics are being discussed, but the proposed solutions are basically 'policies' but no actual mechanisms to enforce those policies are being defined. For example, privacy is not really an issue because the owner can opt to deactivate the service. How? By sending a signed letter to the SO or DENATRAN who then will dutifully disable the device. We'll see how things develop, but probably there will be more outcries about this legislation once the deadline gets even closer and public awareness rises -- Santiago - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Activation protocol for tracking devices
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 majord...@metzdowd.com
Re: Activation protocol for tracking devices
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 majord...@metzdowd.com
Re: Activation protocol for tracking devices
Hi, Jerry Leichter wrote: Not specifically, but you can simply take the first 64 bits from a larger cryptographically secure hash function. OK, I didn't know if it was right to do just that. We were thinking to use that hash in an HMAC so the TCU and SO can know that they were originated from someone who knows Kc and to protect it's integrity (see below). 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. Best if we can avoid trickier things!. I was thinking of a hash so maybe we could reuse the ones we were using on other parts of the protocol (since probably asking to include support for a larger set of primitives on all devices would be resisted); but we can, of course, just require that the TCU generates a random challenge and leave the mechanism to be defined by each implementation. 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. Will take a look at them, thanks. 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). Yes, I was aware of this, the H should be an HMAC. AFAIK it shouldn't be a problem, just some extra cycles and doing it the right way, right? 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. The 64 bits limitation is because the protocol only has 1 slot to include *some* auth information, and it's a 64 bits field (yes, it has been defined without knowing what exactly will go there ;)). The protocol was defined by a working group and trying to changing it can be... complicated... unless we have obvious arguments to show that it's insufficient. By signed I meant doing a HMAC(Kc, body of message (with auth field in 0, sic)). Would it be OK in this case to truncate the output of ie. a HMAC-SHA1 to 64 bits? My crypto/math is not good enough to understand how hard would be in this case to modify a msg to reuse a previous signature. Thanks for your comments Jerry! Regards, -- Santiago - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Activation protocol for tracking devices
As it has been pointed out numerous times on this and other places, this is a singularly bad idea. The crypto isn't even the hardest part (and it's hard enough). Just don't do it. If you are going to spend your energy on anything, it should be to work against such a plan. /ji - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Activation protocol for tracking devices
John Ioannidis wrote: Just don't do it. If you are going to spend your energy on anything, it should be to work against such a plan. I would agree, but I fear that a this is never going to work, drop it will be less heard than any effort in at least trying to raise the bar for an attack. The previous proposed solution at the work group was that the service provider 'configured' the device with an authentication 'word' upon activation an made sure that that 'word' was always present on each message to authenticate it. The only benefit I can see in it (that could very likely been accepted if no one objected) is that is so simple that all bugs are obvious... But I accept that the false sense of security of a complex scheme that is broken somewhere _maybe_ worse than an obviously wrong solution... Santiago. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Activation protocol for tracking devices
On Mar 2, 2009, at 12:56 PM, Santiago Aguiar wrote: Hi, Jerry Leichter wrote: Not specifically, but you can simply take the first 64 bits from a larger cryptographically secure hash function. OK, I didn't know if it was right to do just that. We were thinking to use that hash in an HMAC so the TCU and SO can know that they were originated from someone who knows Kc and to protect it's integrity (see below). All the bits in a cryptographically secure hash function are equally good. So, yes, you can construct a shorter hash by simply discarding bits from a longer one. I would suggest that if you're going to build an HMAC, that you shrink the result as the very last step: Do the internal calculations using the full hash function. I don't see an obvious attack from doing it the other way, but it just seems riskier. 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. Best if we can avoid trickier things!. I was thinking of a hash so maybe we could reuse the ones we were using on other parts of the protocol (since probably asking to include support for a larger set of primitives on all devices would be resisted); but we can, of course, just require that the TCU generates a random challenge and leave the mechanism to be defined by each implementation. 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. Will take a look at them, thanks. Look around for deterministic random number generators or something like that. I'm sure you know this, but do *not* attempt to use a generator designed for statistical purposes - those have good randomness properties but are not secure against deliberate attack. 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). Yes, I was aware of this, the H should be an HMAC. AFAIK it shouldn't be a problem, just some extra cycles and doing it the right way, right? Yes. 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. The 64 bits limitation is because the protocol only has 1 slot to include *some* auth information, and it's a 64 bits field (yes, it has been defined without knowing what exactly will go there ;)). The protocol was defined by a working group and trying to changing it can be... complicated... unless we have obvious arguments to show that it's insufficient. By signed I meant doing a HMAC(Kc, body of message (with auth field in 0, sic)). Would it be OK in this case to truncate the output of ie. a HMAC-SHA1 to 64 bits? My crypto/math is not good enough to understand how hard would be in this case to modify a msg to reuse a previous signature. OK, there is a distinction between a signature and a MAC (Message Authentication Code). The significant difference is that it's possible to prove to a third party that someone signed something without actually having the ability to sign things yourself. (Think RSA signatures: The public key is all you need to prove that something was signed with the corresponding private key; but it's insufficient to sign anything.) A MAC is sufficient for your purpose. It's fine to truncate the output of a MAC computation. In fact, there good reasons for doing so in some situations, independent of the available space: By discarding information, it makes certain attacks harder. You'll see people immediately jump in with but the birthday paradox says you lose half your bits, which is true for a hash, but *not* for a MAC, where the attacker doesn't have access to the key. Thanks for your comments Jerry! You're welcome. I hope they're helpful, but don't rely on them too much - my quick response on a mailing list isn't a serious security analysis of the protocol and implementation. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
