Stuffs to read before going to bed
Re: Stuffs to read before going to bed
A *beep*load of video courses (algebra, calculus, chemistry...) at the Khan academy.
-
- Posts: 38
- Joined: Sun Jun 22, 2008 5:18 pm
- Contact:
Re: Stuffs to read before going to bed
Two research papers about how the encryption keys for the configuration bitstream of a Xilinx FPGA were recovered by monitoring power consumption of the device during decryption:
http://eprint.iacr.org/2011/390.pdf
http://eprint.iacr.org/2011/391.pdf
Figure 4 in the first paper makes it pretty clear.
I wonder what methods could be used to prevent this kind of attack?
You could have some unrelated computationally intensive processing happening concurrently that worked on randomly generated input. This would artificially add to the power consumption so it would be harder to isolate the parts related to decryption. However loading the same encrypted bitstream multiple times would give enough samples that you could remove the random power consumption and isolate the part you want.
Maybe the software that encrypts the bitstream could calculate power consumption during decryption, and provide supplemental data that the hardware used as a flag to generate additional power consumption during non-peak time. Then the device would always appear to be operating at peak consumption during decryption. Still, that data would have to be supplied from the configuration memory and could be examined by a third party too. And maybe implementing something like that is impractical.
Anyway you can see why there's a need for FPGAs that don't require external configuration.
http://eprint.iacr.org/2011/390.pdf
http://eprint.iacr.org/2011/391.pdf
Figure 4 in the first paper makes it pretty clear.
![Smile :)](./images/smilies/icon_e_smile.gif)
You could have some unrelated computationally intensive processing happening concurrently that worked on randomly generated input. This would artificially add to the power consumption so it would be harder to isolate the parts related to decryption. However loading the same encrypted bitstream multiple times would give enough samples that you could remove the random power consumption and isolate the part you want.
Maybe the software that encrypts the bitstream could calculate power consumption during decryption, and provide supplemental data that the hardware used as a flag to generate additional power consumption during non-peak time. Then the device would always appear to be operating at peak consumption during decryption. Still, that data would have to be supplied from the configuration memory and could be examined by a third party too. And maybe implementing something like that is impractical.
Anyway you can see why there's a need for FPGAs that don't require external configuration.
Don't forget your two NOPs after CSH.
Re: Stuffs to read before going to bed
1) internal power source.Charles MacDonald wrote:Two research papers about how the encryption keys for the configuration bitstream of a Xilinx FPGA were recovered by monitoring power consumption of the device during decryption:
I wonder what methods could be used to prevent this kind of attack?
2) dont use a FPGA
3) use bunny security
![Image](http://26.media.tumblr.com/tumblr_lonkmuFoHW1qahhxwo1_500.jpg)
Re: Stuffs to read before going to bed
Or they can wrap the device into a tinfoil hat.
No matter how you put it, that kind of attack is hard to counter. Using a battery or an external source is useless if you have access to it. Randomizing processing can help. But you'll need a true random. Otherwise it'll only slow down the hack the same door locks do with burglars. None are 100% unbreakable![Smile :)](./images/smilies/icon_e_smile.gif)
No matter how you put it, that kind of attack is hard to counter. Using a battery or an external source is useless if you have access to it. Randomizing processing can help. But you'll need a true random. Otherwise it'll only slow down the hack the same door locks do with burglars. None are 100% unbreakable
![Smile :)](./images/smilies/icon_e_smile.gif)
Re: Stuffs to read before going to bed
There were a lot of game source codes released on Romhacking.
- Alter Ego (Nes). It's a kick ass homebrew game! It'll be cool to have a pce port.
- Crystal Mines Source Code
- Boogerman (Nes)
- Pocahontas (Nes)
- Freefall (Nes)
- Hero Quest (Nes)
- John Smith (Nes)
- Magician (Nes)
- Alien 3 music code (Nes) (Jeroen Tel \o/)
- Robocop 3 music code (Nes) (Jeroen Tel again)
- Technocop music code (Nes) (Same as above)
- Final Fantasy 1 music driver (Nes)
-
- Posts: 38
- Joined: Sun Jun 22, 2008 5:18 pm
- Contact:
Re: Stuffs to read before going to bed
This page links to a PDF transcript of a discussion with the Motorola 68000 design team:
http://www.computerhistory.org/collecti ... /102658164
There's a lot of cool stuff in here, like all 680x0 circuitry was tested on breadboards until the 68040, at which point they finally started to simulate the design with FPGAs. And Motorola and Hitachi really worked closely to exchange IP and manufacturing processes for mutual gain, which drastically improved Motorola's fabrication abilities. I guess that makes it no surprise that Hitachi second-sourced nearly everything Motorola made back then.
I wish they'd had discussed the often overlooked 68012 and had included people from the 68060 team, but regardless it's a great read.
http://www.computerhistory.org/collecti ... /102658164
There's a lot of cool stuff in here, like all 680x0 circuitry was tested on breadboards until the 68040, at which point they finally started to simulate the design with FPGAs. And Motorola and Hitachi really worked closely to exchange IP and manufacturing processes for mutual gain, which drastically improved Motorola's fabrication abilities. I guess that makes it no surprise that Hitachi second-sourced nearly everything Motorola made back then.
I wish they'd had discussed the often overlooked 68012 and had included people from the 68060 team, but regardless it's a great read.
Don't forget your two NOPs after CSH.
Re: Stuffs to read before going to bed
-
- Posts: 38
- Joined: Sun Jun 22, 2008 5:18 pm
- Contact:
Re: Stuffs to read before going to bed
Here's a good article about how voltage at an I/O pin of an unpowered chip can find a path to the supply rail through ESD protection diodes:
http://www.analog.com/library/analogDia ... _amps.html
I have an interesting real-world example to add to this:
The Sega Saturn Action Replay cartridge connects to a Comms Link ISA card using an 8-bit bidirectional data bus. The card has a '573 latch which connects to a '245 transceiver in the cartridge. If the Saturn is turned off and the '573 latch value is non-zero (one or more data lines driven high), current will flow from the '573 Q pins to the '245 input pins, then through the ESD protection diodes in each pin to the Saturn's +5V rail. In this way the PC powers the Saturn.
In fact this is sufficient enough that the number of set bits in the '573 latch corresponds to the brightness of the Saturn's power LED.![Smile :)](./images/smilies/icon_e_smile.gif)
One problem is that this low voltage on the +5V rail prevents the reset generator from detecting a power-up event as the system is already powered to some extent, presumably past the trip point. So switching on the Saturn does not cause a reset pulse to be generated and the various components are left in an undefined state. You have to run a program on the PC to clear the latch to make the Saturn boot correctly.
The author's suggestion of adding series resistors to limit current would probably work in this case, though the article focuses on op-amps. For unidirectional signals you could use isolation like an optocoupler, and I could swear TI makes level shifters that deliberately omit the ESD diodes for this purpose, but I can't find the part number. When you are mixing powered and unpowered ICs it can be quite an issue to overcome.
EDIT: The last section in this application note discusses this issue for CMOS-based digital logic:
http://www.fairchildsemi.com/an/AN/AN-376.pdf
In particular tri-stating the output of a powered IC that connects to an unpowered IC seems to be the trick. ;D
http://www.analog.com/library/analogDia ... _amps.html
I have an interesting real-world example to add to this:
The Sega Saturn Action Replay cartridge connects to a Comms Link ISA card using an 8-bit bidirectional data bus. The card has a '573 latch which connects to a '245 transceiver in the cartridge. If the Saturn is turned off and the '573 latch value is non-zero (one or more data lines driven high), current will flow from the '573 Q pins to the '245 input pins, then through the ESD protection diodes in each pin to the Saturn's +5V rail. In this way the PC powers the Saturn.
In fact this is sufficient enough that the number of set bits in the '573 latch corresponds to the brightness of the Saturn's power LED.
![Smile :)](./images/smilies/icon_e_smile.gif)
One problem is that this low voltage on the +5V rail prevents the reset generator from detecting a power-up event as the system is already powered to some extent, presumably past the trip point. So switching on the Saturn does not cause a reset pulse to be generated and the various components are left in an undefined state. You have to run a program on the PC to clear the latch to make the Saturn boot correctly.
The author's suggestion of adding series resistors to limit current would probably work in this case, though the article focuses on op-amps. For unidirectional signals you could use isolation like an optocoupler, and I could swear TI makes level shifters that deliberately omit the ESD diodes for this purpose, but I can't find the part number. When you are mixing powered and unpowered ICs it can be quite an issue to overcome.
EDIT: The last section in this application note discusses this issue for CMOS-based digital logic:
http://www.fairchildsemi.com/an/AN/AN-376.pdf
In particular tri-stating the output of a powered IC that connects to an unpowered IC seems to be the trick. ;D
Don't forget your two NOPs after CSH.
Re: Stuffs to read before going to bed
So that may explain some weird behaviour on some electronic equipements?
By the way, here's the LM13600/LM13700 story.
By the way, here's the LM13600/LM13700 story.