Can the system datalinks be hardware encrypted?

[MadRat]

I thought that the XBOX was encrypted on the hardware level but it turns out the encryption is done in the BIOS, which is soft programming. Is there a hardware method to scramble data in order to keep a system free from pryng eyes?

 

[rbhawcroft]

no. unless you want to burn a new algorythm on each chip. with the xbox the mistake was not to let the bios be on the cpu die, or not to do the encryption processing on the cpu off a die based ROM any way, as far as I understand it right now.

 

[Carceri]

Sure you could implement an encryption algorithm in hardware and integrate it into the CPU or any other chip that needed to communicate securely. The problem is that you need to store the key somewhere, and having to actually make the key a part of the chip would probably be very expensive since you need to do that to every chip with a different key. Also you can't just replace one faulty chip since it wouldn't be able to communicate with the other components.

 

[rbhawcroft]

Originally posted by: Carceri
Sure you could implement an encryption algorithm in hardware and integrate it into the CPU or any other chip that needed to communicate securely. The problem is that you need to store the key somewhere, and having to actually make the key a part of the chip would probably be very expensive since you need to do that to every chip with a different key. Also you can't just replace one faulty chip since it wouldn't be able to communicate with the other components.

bear with me as im not an EE, but surely if you only have one algorithm on every die then the key is easily crackable, unless the key is the entire BIOS programme, in which case you couldnt change the BIOS. Also isnt it possible to have a separate BIOS only bus and embed the BIOS chip under another chip or inside a multi layered circuit board?

 

[pm]

You could use on-die electrically programmable one-time fuses to program the key. This way it would be one-time programmable, different per chip, and reverse-engineering the chip wouldn't buy you much since you still wouldn't know the key that is on another chip. On-die fuses are fairly commonplace in the industry now and they aren't that expensive to implement.

 

[rbhawcroft]

Originally posted by: pm
You could use on-die electrically programmable one-time fuses to program the key. This way it would be one-time programmable, different per chip, and reverse-engineering the chip wouldn't buy you much since you still wouldn't know the key that is on another chip. On-die fuses are fairly commonplace in the industry now and they aren't that expensive to implement.

will paladium use on-die technology to ensure that its not cracked at OS level?

 

[Shalmanese]

The thing is, once the encrytion algorithm is cracked or a flaw is found, you cant patch it so your entire infrastructure goes down the drain.

 

[pm]

Encryption algorithms are pretty good nowadays, RC5 and 3-DES are both well known algorithms that produce high levels of encryption if the keys are long and chosen wisely . It is unlikely that factoring large numbers will be faster in the future, so I don't see how the algorithm could be broken - again, provided that the key is sufficiently long and it is well chosen. You could implement a well known algorithm in logic, use fuses to create the key and you could have a fairly high level of confidence that the system will be pretty good. The obvious counter-example is WEP, but WEP wasn't broken because the algorithm was inherently flawed but due to poor choices of keys and key length, IMO. There were some implementation choices which were poor, but the overall RC4 algorithm is reasonably secure as long as the key is sufficiently long (which, in the case of WEP, it's not) and well chosen to be difficult to determine.

 

[Mark R]

I thought that the XBOX was encrypted on the hardware level but it turns out the encryption is done in the BIOS, which is soft programming

The encryption for the XBOX, is in the BIOS - but, you won't find the decryption routine in the BIOS chip. The BIOS chip, if it is read, and disassembled will only reveal a defective decryption program, that won't decrypt anything. The real decryption program and key are hidden inside the chipset; the decryption key in the BIOS chip is just a decoy.

The mistake in the XBOX was assuming that it was impractical to spy on the 800 MHz hypertransport bus - by intercepting these transmissions, it was possible to see, exactly what commands the CPU was executing, and what data it was getting.

It is quite practical to include a hardware decryption system in a modern chip - especially one as complex as a CPU or chipset, but its use will add considerably latency, meaning that you would need a seperate, 'secure' bus - which is not necessarily a problem.

Similarly, there is no real need to have a different key for every different chip - every XBOX uses the same decryption key. The balance of costs, in terms of risk of key being discovered, importance of a third party discovering the key, and cost of implementing a unique key for each device, could favour either one key per design, or one key per individual device, depending on the circumstances.

 

[pm]

Similarly, there is no real need to have a different key for every different chip - every XBOX uses the same decryption key. The balance of costs, in terms of risk of key being discovered, importance of a third party discovering the key, and cost of implementing a unique key for each device, could favour either one key per design, or one key per individual device, depending on the circumstances.

If you didn't implement a different key per chip then it wouldn't be a difficult task to reverse engineer the key using an E-Beam Probe to figure it out, or simply to strip back the chip and see what the logic ROM for the key is. Admittedly these techniques would be outside the realm of the average home user (since a E-Beam probe must run well into the millions of dollars and it still requires a tester to exercise the chip while you are probing it), but if absolute security is required then the best way to implement it is using on chip fuses to program a unique key.

I agree with your point about latency. One reason for RC4 on WEP was that it is relatively fast to implement on die. XOR's are easy, well known and fairly fast circuits. Upgrading to another algorithm would slow things down significantly.

 

[MadRat]

Perhaps a short list of common keys could be supplemented with another short list of unique keys? This way the chipset and processor could exchange the current "safe" key using a time stamp and known key, which would be changed after a short period anyhow, so interception of the keys would be largely futile. Is my logic of using time stamps and known keys to select a unique key sound?

 

[Carceri]

Encryption algorithms are pretty good nowadays, RC5 and 3-DES are both well known algorithms that produce high levels of encryption if the keys are long and chosen wisely . It is unlikely that factoring large numbers will be faster in the future, so I don't see how the algorithm could be broken - again, provided that the key is sufficiently long and it is well chosen.

RC5 and 3DES are not related to the factoring of large numbers. Still your point is valid. I don't see algorithms like 3DES, Rijndael, Mars, Serpent, RC5, RC4, RC6, IDEA, CAST, etc... being broken in the near future (if ever).

You could implement a well known algorithm in logic, use fuses to create the key and you could have a fairly high level of confidence that the system will be pretty good.

That was my point. Of cause you could look into the chip to read out the key, but that will be out of the scope for "regular" people. Also if each unit was made with it's own unique keys getting the key for one unit would not help getting the keys for other units. But as mentioned before that would be expensive to produce and to repair such a unit (the same key needs to be in every chip that needs to communicate and if one fails it can't be replaced by another because the key is not known once the chip is produced).

The obvious counter-example is WEP, but WEP wasn't broken because the algorithm was inherently flawed but due to poor choices of keys and key length, IMO.

WEP suffers from an attack found by (of cause ) Adi Shamir against the key scheduling algorithm of the RC4 algorithm. Nearly any product that uses RC4 is affected. The attack scales linearly with the key size, so even the maximum keysize of RC4 (2048 bits) is easy to break. It's a passive attack that uses a lot of data encrypted under the same key, which is easy to gather with WEP since a lot of packets are transmitted that are encrypted under the samy key.

This attack can be thwarted by either changing encryption keys often (and avoid certain weak keys that allows the attack to be performed with very little cipher text) or making a small modification to the RC4 key generation (simply repeat the state array mixing loop a few times instead of running it only once)

 

[pm]

RC5 and 3DES are not related to the factoring of large numbers.

True. I'd originally written RSA instead of RC5 and then later corrected it through an edit after I thought about the fact that RSA is a method for exchanging keys - not an encryption algorithm. But I forgot and then left the factoring bit in.

WEP suffers from an attack found by (of cause ) Adi Shamir against the key scheduling algorithm of the RC4 algorithm. Nearly any product that uses RC4 is affected. The attack scales linearly with the key size, so even the maximum keysize of RC4 (2048 bits) is easy to break.

I wouldn't have said that a key of 2048 bits is easy to break under RC4. More like it's possible to break it. A larger key length in WEP would make the system more secure than it currently is - it wouldn't be totally secure, but it might make it "secure enough" for typical applications. But I take your point and stand corrected.

That was my point. Of cause you could look into the chip to read out the key, but that will be out of the scope for "regular" people. Also if each unit was made with it's own unique keys getting the key for one unit would not help getting the keys for other units. But as mentioned before that would be expensive to produce and to repair such a unit (the same key needs to be in every chip that needs to communicate and if one fails it can't be replaced by another because the key is not known once the chip is produced).

One-time electrically programmable fuses are not particularly expensive to integrate into a process - most of the major CPU's out there have them. They aren't cheap, but they aren't prohibitive either. As far as the interaction between different chips, you could exchange keys using a technique like RSA as part of the initialization routine - particularly on the newer style of buses that require frequent handshaking to resynchronize. It all depends on the level of confidence required that the data will be secure versus the cost/performance penalty incurred.

If nothing else, it's interesting to tihnk about how you could build a theoretical system with encrypted communication.

 

[Shalmanese]

Im not arguring about the algorithms so much as the implementation. Every system built is going to have bugs and unintentional backdoors and faults and weaknesses. The point is, I wouldn't trust any program to do my encrypting of sensitive data UNLESS its source has been tossed around by the encryption community for a couple of years. there are STILL security flaws being found in PGP/Secure BSD etc. The thing is, once those flaws are brought to light, they can be patch. With hardware, if a flaw is found, you essentially screwed.

Another possible apocryphal anecdote: When the DES standard was being finalised, it was sent to the NSA for a final lookup who, apprently unaware that this was going to be a public standard, reccomended several apparently trivial changes. 5 or so years later, some german scientists found that one of the flaws with the DES algorithm was that for a very limited range of numbers, it was far easier to crack the code. Those numbers turned out to be exactly the ones the NSA said shouldnt be included into the standard.

 

[rbhawcroft]

Originally posted by: Carceri

Encryption algorithms are pretty good nowadays, RC5 and 3-DES are both well known algorithms that produce high levels of encryption if the keys are long and chosen wisely . It is unlikely that factoring large numbers will be faster in the future, so I don't see how the algorithm could be broken - again, provided that the key is sufficiently long and it is well chosen.

RC5 and 3DES are not related to the factoring of large numbers. Still your point is valid. I don't see algorithms like 3DES, Rijndael, Mars, Serpent, RC5, RC4, RC6, IDEA, CAST, etc... being broken in the near future (if ever).

You could implement a well known algorithm in logic, use fuses to create the key and you could have a fairly high level of confidence that the system will be pretty good.

That was my point. Of cause you could look into the chip to read out the key, but that will be out of the scope for "regular" people. Also if each unit was made with it's own unique keys getting the key for one unit would not help getting the keys for other units. But as mentioned before that would be expensive to produce and to repair such a unit (the same key needs to be in every chip that needs to communicate and if one fails it can't be replaced by another because the key is not known once the chip is produced).

The obvious counter-example is WEP, but WEP wasn't broken because the algorithm was inherently flawed but due to poor choices of keys and key length, IMO.

WEP suffers from an attack found by (of cause ) Adi Shamir against the key scheduling algorithm of the RC4 algorithm. Nearly any product that uses RC4 is affected. The attack scales linearly with the key size, so even the maximum keysize of RC4 (2048 bits) is easy to break. It's a passive attack that uses a lot of data encrypted under the same key, which is easy to gather with WEP since a lot of packets are transmitted that are encrypted under the samy key.This attack can be thwarted by either changing encryption keys often (and avoid certain weak keys that allows the attack to be performed with very little cipher text) or making a small modification to the RC4 key generation (simply repeat the state array mixing loop a few times instead of running it only once)

I THOUGHT THE POINT OF THE DISCUSSION WAS NOT COMMUNICATIONS ENCRYPTION BUT SECUREING DRM ON SYSTEMS THAT GO TO THE END USER. (sorry just noticed caps lock on)
so you could have a unique key on each system, because the key is only used for ensuring bios and boot process and OS are uncracked.
on the xbox the key was available so the bios could be opened up and the a new dual boot bios reflashed in its place, which brings me to my point either hardcode the bios, or use key parts of it as the actual key, or embed the bios in a place that is unaccessible to a reflasher, ie on die, or under another chip or inside a multilayered board.i think using key parts of the bios as the key or multiple keys is the best idea as it would mean you could update the bios a little bit but not modify key data blocks, is this a workable idea?

the point of wep encryption is to swap keys every few minutes, although a spy could data mine and run lengthy cracking runs using every key it would be pretty difficult to resolve useful data.

 

[Mark R]

which brings me to my point either hardcode the bios, or use key parts of it as the actual key, or embed the bios in a place that is unaccessible to a reflasher, ie on die, or under another chip or inside a multilayered board.i think using key parts of the bios as the key or multiple keys is the best idea as it would mean you could update the bios a little bit but not modify key data blocks, is this a workable idea?

Well, it is - it was done in the XBOX. The critical parts of the BIOS (namely the parts that decrypt and authenticate the rest of the BIOS) are embedded into the chipset. An attacker would be thwarted because if the BIOS EEPROM was reflashed, the code would fail to execute because the BIOS loader would reject it. A genuine BIOS would be recognised as such by the BIOS loader and would then be executed.

This system was defeated by a novel method which spied on the actual data sent to the CPU, not what was retrieved from EEPROM. If the hypertransport bus, which had previously been regarded as a low security bus, had been hidden inside the board, then the attack would have been harder - however, a determined attacker could still have intercepted the CPUs FSB (no software, no matter how cleverly hidden, unless it is integrated on the CPU die, could withstand that attack).

If the critical BIOS code had been integrated into the CPU, the system would have been more secure. Nevertheless, a very determined and highly funded attacker could still retrieve the key, by examining the CPU die - However, in the case of the XBOX, it is unlikely that anyone would have bothered.

Essentially, software can only offer limited security against a determined attacker - a true hardware solution is preferable.

 

[Carceri]

I thought about the fact that RSA is a method for exchanging keys - not an encryption algorithm

RSA is an encryption algorithm, but is normally used to encrypt a small piece of random data to be used as a key for a faster conventional algorithm since RSA is extremely slow. You were probably thinking of the Diffie-Hellman key exchange protocol which is used only for exchanging keys.

I wouldn't have said that a key of 2048 bits is easy to break under RC4.

Given enough ciphertext is actually is easy. Easy enough that it can be broken in a few days using a single PC.

As far as the interaction between different chips, you could exchange keys using a technique like RSA as part of the initialization routine - particularly on the newer style of buses that require frequent handshaking to resynchronize. It all depends on the level of confidence required that the data will be secure versus the cost/performance penalty incurred

The best way to do this (I think - haven't given it much thought) would be to include a shared secret in each chip (we can call it a key) and then use RSA (or any other algorithm suitable for that purpose) to exhange a new key every few minutes using the shared secret to authenticate each chip. Without the shared secret the scheme with just using RSA to exchange keys could be broken with a simple man-in-the-middle attack. By exchanging keys regularily we lower the amount of data encrypted under a specific key which makes cryptoanalysis more difficult (and could make an attack such as the one against RC4 impractical)

Actually I believe that any method to secure communication between nodes in a network could be applied in this case too.

The problem here is probably the cost. Including hardware support for RSA and some other conventional encryption algorithm in each chip doesn't come for free. But as you said... It all depends on the level of security you want vs. what you are willing to pay for it.

 

[rbhawcroft]

Well, it is - it was done in the XBOX. The critical parts of the BIOS (namely the parts that decrypt and authenticate the rest of the BIOS) are embedded into the chipset. An attacker would be thwarted because if the BIOS EEPROM was reflashed, the code would fail to execute because the BIOS loader would reject it. A genuine BIOS would be recognised as such by the BIOS loader and would then be executed.This system was defeated by a novel method which spied on the actual data sent to the CPU, not what was retrieved from EEPROM. If the hypertransport bus, which had previously been regarded as a low security bus, had been hidden inside the board, then the attack would have been harder - however, a determined attacker could still have intercepted the CPUs FSB (no software, no matter how cleverly hidden, unless it is integrated on the CPU die, could withstand that attack).If the critical BIOS code had been integrated into the CPU, the system would have been more secure. Nevertheless, a very determined and highly funded attacker could still retrieve the key, by examining the CPU die - However, in the case of the XBOX, it is unlikely that anyone would have bothered.Essentially, software can only offer limited security against a determined attacker - a true hardware solution is preferable.

so how is linux runnable on the xbox? some guy from MIT managed to get linux to run on the xbox about 10 weeks ago.

so is it that the bios programme was encrypted with a key that was transmitted unencrytpted and the cpu then checks for some of the bios code after it has been decrytped in the CPU? basically i dont understand how that guy got linux running if the bios was supposed to be unmodifiable.

 

[Mark R]

The CPU has to retrieve the key and decryption software (stored in the critical area) - which means that both have to be transmitted in the clear over the FSB, and hypertransport link.

Once the key was retrieved, it would be quite straightforward to decrypt the old BIOS, and to encrypt and sign a new version.

During boot the CPU will run the following programs:
1) BIOS loader: Decrypts and verifies the main BIOS. (This program is hidden within a critical chipset part)
2) BIOS. Main BIOS functionality, plus decryption and authentication code for the OS loader (This program is stored on the BIOS EEPROM)
3) OS loader. Decrypts and verifies the OS (stored on HD)
4) OS. Verifies software before execution

This attack works by retrieving the BIOS loader. Once the loader was retrieved and analysed, it is easy to rewrite the BIOS and sign it so that it is accepted as genuine by the BIOS loader. Once security is compromised at this stage, the rest of the chain collapses.

 

[rbhawcroft]

Originally posted by: Mark R
The CPU has to retrieve the key and decryption software (stored in the critical area) - which means that both have to be transmitted in the clear over the FSB, and hypertransport link.Once the key was retrieved, it would be quite straightforward to decrypt the old BIOS, and to encrypt and sign a new version.During boot the CPU will run the following programs:1) BIOS loader: Decrypts and verifies the main BIOS. (This program is hidden within a critical chipset part)2) BIOS. Main BIOS functionality, plus decryption and authentication code for the OS loader (This program is stored on the BIOS EEPROM)3) OS loader. Decrypts and verifies the OS (stored on HD)4) OS. Verifies software before executionThis attack works by retrieving the BIOS loader. Once the loader was retrieved and analysed, it is easy to rewrite the BIOS and sign it so that it is accepted as genuine by the BIOS loader. Once security is compromised at this stage, the rest of the chain collapses.

oh ok thanks. so the BIOS loader only checks small parts of the actual BIOS, but cant be altered so if you want to do a linux dual boot you would have to modify the new BIOS so that the BIOS loader thinks that it is a genuine BIOS.