How secure is OTAR?
Moderator: Queue Moderator
- fogster
- Posts: 386
- Joined: Sun Nov 06, 2005 10:38 am
- What radios do you own?: XTS2500/5000, XPR7550/5550
How secure is OTAR?
I was reading up a bit on how OTAR (Over The Air Rekeying), It looks like each radio is loaded with an encryption key (the KEK, or "Key Encryption Key"), and the new 'voice key' is sent out encrypted with the KEK.
This leads me to two questions:
- If I'm an evil archvillian trying to crack the secure comms, what stops me from just cracking the KEK? If I crack the KEK, I know the key for whatever voice comms you use, so the voice encryption is basically useless. (And if the KEK is astronomically more secure than the voice key, why not just use the KEK to encrypt voice traffic?)
- If the evil archvillian, instead of running his underground lair of supercomputers, just goes and steals someone's radio, doesn't he then know the KEK? And, provided he can figure out a way to keep the stolen radio from being inhibited (perhaps be could ask on Batboard), wouldn't the radio receive all key updates, thus being able to listen to all traffic until the radios were physically reprogrammed with a new KEK?
Do I misunderstand a step? Because it seems to me like the only way to keep OTAR secure is to physically put new KEKs into the radios very often. (But if you're doing that, you might as well skip OTAR and just put new voice keys in?)
This leads me to two questions:
- If I'm an evil archvillian trying to crack the secure comms, what stops me from just cracking the KEK? If I crack the KEK, I know the key for whatever voice comms you use, so the voice encryption is basically useless. (And if the KEK is astronomically more secure than the voice key, why not just use the KEK to encrypt voice traffic?)
- If the evil archvillian, instead of running his underground lair of supercomputers, just goes and steals someone's radio, doesn't he then know the KEK? And, provided he can figure out a way to keep the stolen radio from being inhibited (perhaps be could ask on Batboard), wouldn't the radio receive all key updates, thus being able to listen to all traffic until the radios were physically reprogrammed with a new KEK?
Do I misunderstand a step? Because it seems to me like the only way to keep OTAR secure is to physically put new KEKs into the radios very often. (But if you're doing that, you might as well skip OTAR and just put new voice keys in?)
-
- No Longer Registered
- Posts: 872
- Joined: Tue Feb 22, 2005 7:03 am
OK, you are positing that you crack the KEK.
First, you have to get some crackable data encrypted with the KEK - and the only time such data is available is when OTAR is happening. This is very infrequent relative to the amount of time the voice keys are running, so you get very little OTAR data to work with for any unit time.
Next, you have to crack the data. Let's assume they are stupid enough to be using single DES for the crack, not 3DES or AES. The algorithms to crack DES require you to have a fair amount of data to crack. The data sent for OTAR is small. You really won't get enough data to do anything other than a brute force attack - all the sophisticated cracks take a lot more data.
Meanwhile, part of the OTAR data can be a new KEK, to be used on the next round. This means that you have to crack the old KEK *before* the new OTAR round occurs if you want to be able to decode the data in real time.
Lastly, assuming you can extract the KEK from a radio (which they are designed to prevent - open the case and the radio will purge all data). Part of the idea of OTAR is that you have multiple KEKs. Assume a fleet of 1024 radios - you can use 20 KEKs, assigning each radio a unique set of 10 KEKs from that twenty. If you know a radio has been stolen, you can rekey the remaining radios by picking KEKs from the set of KEKs that the stolen radio does not have.
Bottom line: Yes, you might be able to crack the rekeying - long after the fact. It won't help you be able to eavesdrop on the conversations in real time. It would be far easier to steal a radio.
Remember: security is a journey, not a destination - there is no such thing as "secure", just "more secure" and "less secure", and all security is properly rated not in terms of "can this be cracked" but rather in terms of "how long will this take to crack."
First, you have to get some crackable data encrypted with the KEK - and the only time such data is available is when OTAR is happening. This is very infrequent relative to the amount of time the voice keys are running, so you get very little OTAR data to work with for any unit time.
Next, you have to crack the data. Let's assume they are stupid enough to be using single DES for the crack, not 3DES or AES. The algorithms to crack DES require you to have a fair amount of data to crack. The data sent for OTAR is small. You really won't get enough data to do anything other than a brute force attack - all the sophisticated cracks take a lot more data.
Meanwhile, part of the OTAR data can be a new KEK, to be used on the next round. This means that you have to crack the old KEK *before* the new OTAR round occurs if you want to be able to decode the data in real time.
Lastly, assuming you can extract the KEK from a radio (which they are designed to prevent - open the case and the radio will purge all data). Part of the idea of OTAR is that you have multiple KEKs. Assume a fleet of 1024 radios - you can use 20 KEKs, assigning each radio a unique set of 10 KEKs from that twenty. If you know a radio has been stolen, you can rekey the remaining radios by picking KEKs from the set of KEKs that the stolen radio does not have.
Bottom line: Yes, you might be able to crack the rekeying - long after the fact. It won't help you be able to eavesdrop on the conversations in real time. It would be far easier to steal a radio.
Remember: security is a journey, not a destination - there is no such thing as "secure", just "more secure" and "less secure", and all security is properly rated not in terms of "can this be cracked" but rather in terms of "how long will this take to crack."
This is my opinion, not Aeroflex's.
I WILL NOT give you proprietary information. I make too much money to jeopardize my job.
I AM NOT the Service department: You want official info, manuals, service info, parts, calibration, etc., contact Aeroflex directly, please.
I WILL NOT give you proprietary information. I make too much money to jeopardize my job.
I AM NOT the Service department: You want official info, manuals, service info, parts, calibration, etc., contact Aeroflex directly, please.
- fogster
- Posts: 386
- Joined: Sun Nov 06, 2005 10:38 am
- What radios do you own?: XTS2500/5000, XPR7550/5550
Well, to make sure we're clear, I'm discussing the hypothetical possibility of doing it. I haven't cracked any KEKs, nor do I plan to. (Nor do I think it's within the realm of possibility for Joe Q. Average.)Wowbagger wrote:OK, you are positing that you crack the KEK.
I really don't know much about how this all works. (As might be evident by me asking these questions?) How are KEKs encrypted? Do they use the same encryption methods as the 'normal' encryption module, or are they separate?Next, you have to crack the data. Let's assume they are stupid enough to be using single DES for the crack, not 3DES or AES.
For the average person, such as a bored geek like me, cracking this is completely infeasible. But suppose momentarily that I worked for that drug lord who was moving $200 million in drugs a day before he died, or that I work in intelligence in a foreign country. They'd have no problem dropping a few million dollars for equipment to crack--brute force if needed--the keys.The algorithms to crack DES require you to have a fair amount of data to crack. The data sent for OTAR is small. You really won't get enough data to do anything other than a brute force attack - all the sophisticated cracks take a lot more data.
But if I record you every time you send out a new KEK, once I get the first one, I can decrypt any subsequent KEKs you send, since they're encrypted with the KEK that I now know.Meanwhile, part of the OTAR data can be a new KEK, to be used on the next round. This means that you have to crack the old KEK *before* the new OTAR round occurs if you want to be able to decode the data in real time.
That's also something I didn't know happened. I had figured that someone with enough know-how and equipment could just manually read the data out of the radio. This would be much more difficult if the data was erased upon opening the radio. (But in that case, if I stole the radio, I'd just keep it, rather than dissecting it.)Lastly, assuming you can extract the KEK from a radio (which they are designed to prevent - open the case and the radio will purge all data).
This is where my idea would fall apart, as I didn't know a radio could hold multiple KEKs. However, that assumes that the organization actually loads up all 20 KEKs and routinely mixes up which one they use. Does that happen in practice, or do most OTAR users just throw one KEK in the radio and rekey over the air after that? (It also sounds to me like it'd be extremely challenging to know what string of keys to send to update the keys on the others in response to a particular radio being stolen.)Part of the idea of OTAR is that you have multiple KEKs. Assume a fleet of 1024 radios - you can use 20 KEKs, assigning each radio a unique set of 10 KEKs from that twenty. If you know a radio has been stolen, you can rekey the remaining radios by picking KEKs from the set of KEKs that the stolen radio does not have.
But to the few people that would be trying to crack voice, they might as well go after the KEK. And those few people are probably the ones who can afford enormous computing power to do the cracking, If KEKs aren't being changed too regularly, they only need to crack one and record the others being sent, and they'd be golden.Bottom line: Yes, you might be able to crack the rekeying - long after the fact. It won't help you be able to eavesdrop on the conversations in real time.
Agreed. (Unless you didn't want to raise suspicions.) It just seems to me like, if you're able to crack the encryption on voice traffic (presumably the reason OTAR exists in the first place), you'd just go after the KEK instead.It would be far easier to steal a radio.
there is no such thing as "secure", just "more secure" and "less secure", and all security is properly rated not in terms of "can this be cracked" but rather in terms of "how long will this take to crack."[/i]
Oh, I agree, and would even say that running a single key, never changed, with no OTAR would keep 99.999% of unwanted listeners out. It's just that the 0.001% that it wouldn't stop is the same 0.001% that would probably have the means to crack the KEKs.
Since your original question is about the 'security' of OTAR, it boils down to usage, as well as frequency of OTAR key changes per system.
OTAR is a 'method' of rekeying radios only, the operation of OTAR is not secure by itself, only the small packet of data that it transmits may be of use....IF you can capture the entire data stream, one misplaced bit here or there and the entire string is useless.
Without the proper KMC ID, even a correct key would not be able to be received from the system as the KMC data is incorrect, and therefore, useless, so the radio does not 'know' how to request a key, nor who from as well.
When the key is received, an OTAR acknowledgement is sent to indicate success of the OTAR, and the console sends the reply to the portable or mobile.
To inhibit or uninhibit a radio, MDC must be enabled on the radio for the console commands to function, simply having MDC is not good enough to 'stun' a radio, it MUST be enabled and active on the channel the inhibit command is sent over.
Same goes for OTAR and other console commands, if the KEK and KMC data is incorrect, the rekey of that radio will not take place and must return the radio so that it can be manually rekeyed with the new KEK and KMC ID, then the radio can once again be OTAR'd in the field.
As Wowbagger stated, the OTAR command string is short in duration, so the chances of it being deciphered properly is ultra slim at best.
"Borrowing' a radio to read the KEK and KMC ID would probaly be the best answer as I doubt all similar data is changed on a regular basis due to complexity of management, but I don't doubt many agencies DO routinely make these changes, especially federal agencies to keep their spying out of the private citizen's ears, and out of the criminal's as well.
You could always 'spoof' the ID and the radio's data and gain access to a rekey, but if that 'borrowed' radio is turned off to prevent the console from detecting two identical IDs on the same network at the same time.
Conventional systems are a lot simpler to do this with than trunked, due to the handshaking that takes place with every trunked radio.
Conventional radios do not autoafilliate to the system like trunked radios do, and that eases the probability of getting caught with a bogus radio ID that would probably be easily captured by the trunked system's controller, which searches for bogus IDs on the system, then sends an inhibit command to that bogus ID so that it can no longer be used.
OTAR is a 'method' of rekeying radios only, the operation of OTAR is not secure by itself, only the small packet of data that it transmits may be of use....IF you can capture the entire data stream, one misplaced bit here or there and the entire string is useless.
Without the proper KMC ID, even a correct key would not be able to be received from the system as the KMC data is incorrect, and therefore, useless, so the radio does not 'know' how to request a key, nor who from as well.
When the key is received, an OTAR acknowledgement is sent to indicate success of the OTAR, and the console sends the reply to the portable or mobile.
To inhibit or uninhibit a radio, MDC must be enabled on the radio for the console commands to function, simply having MDC is not good enough to 'stun' a radio, it MUST be enabled and active on the channel the inhibit command is sent over.
Same goes for OTAR and other console commands, if the KEK and KMC data is incorrect, the rekey of that radio will not take place and must return the radio so that it can be manually rekeyed with the new KEK and KMC ID, then the radio can once again be OTAR'd in the field.
As Wowbagger stated, the OTAR command string is short in duration, so the chances of it being deciphered properly is ultra slim at best.
"Borrowing' a radio to read the KEK and KMC ID would probaly be the best answer as I doubt all similar data is changed on a regular basis due to complexity of management, but I don't doubt many agencies DO routinely make these changes, especially federal agencies to keep their spying out of the private citizen's ears, and out of the criminal's as well.
You could always 'spoof' the ID and the radio's data and gain access to a rekey, but if that 'borrowed' radio is turned off to prevent the console from detecting two identical IDs on the same network at the same time.
Conventional systems are a lot simpler to do this with than trunked, due to the handshaking that takes place with every trunked radio.
Conventional radios do not autoafilliate to the system like trunked radios do, and that eases the probability of getting caught with a bogus radio ID that would probably be easily captured by the trunked system's controller, which searches for bogus IDs on the system, then sends an inhibit command to that bogus ID so that it can no longer be used.
That is what the verb "to posit" means - to assume for the purposes of discussionfogster wrote:Well, to make sure we're clear, I'm discussing the hypothetical possibility of doing itWowbagger wrote:OK, you are positing that you crack the KEK.
FIrst, let us correct your statement. It is the OTAR data that is encrypted *with* a KEK, by employing some algorithm. You don't encrypt a KEK any more than you lock a key.fogster wrote:I really don't know much about how this all works. (As might be evident by me asking these questions?) How are KEKs encrypted? Do they use the same encryption methods as the 'normal' encryption module, or are they separate?Next, you have to crack the data. Let's assume they are stupid enough to be using single DES for the crack, not 3DES or AES.
Now, the OTAR data might contain new KEKs, which would, as they are part of the OTAR data, be encrypted.
And yes, the OTAR data can be encrypted with any of the algorithms the radio understands - so the OTAR data might very well be encoded using 256AES.
OK, let's try this again. Sure, you can decode the last keying data - say, three days later. During that three days, you cannot decode the conversations going over the air. The only thing you could do would be to record the data, and decode it in three days, when you have broken the OTAR data. Since the data going over the radio is of a tactical nature only, in three days it is of no interest - our hypothetical drug lords don't benefit from the knowledge that TAC team two is going to kick in their door - two days ago.fogster wrote:But if I record you every time you send out a new KEK, once I get the first one, I can decrypt any subsequent KEKs you send, since they're encrypted with the KEK that I now know.Meanwhile, part of the OTAR data can be a new KEK, to be used on the next round. This means that you have to crack the old KEK *before* the new OTAR round occurs if you want to be able to decode the data in real time.
And as I said - that's assuming you can break the key. Don't let anybody fool you - brute forcing even single DES, with a 56 bit keyspace, isn't trivial. Even at a billion keys per second, that is over 2 years to cover the whole keyspace. The tricks for breaking DES all assume you have a large amount of data to work with - and again, you don't with OTAR.
Also, nobody in their right minds will use OTAR with single DES - you'd use 3DES *at least* if not 256AES. Current theory of computational quantum dynamics indicates that to brute force 256AES would take a computer running as hot as a star, as large as a star, running for roughly the lifetime of a star, to crack.
This is my opinion, not Aeroflex's.
I WILL NOT give you proprietary information. I make too much money to jeopardize my job.
I AM NOT the Service department: You want official info, manuals, service info, parts, calibration, etc., contact Aeroflex directly, please.
I WILL NOT give you proprietary information. I make too much money to jeopardize my job.
I AM NOT the Service department: You want official info, manuals, service info, parts, calibration, etc., contact Aeroflex directly, please.