Stuffs to read before going to bed

Random unmapped chat
Post Reply
User avatar
MooZ
Site Admin
Posts: 407
Joined: Sun Jun 22, 2008 3:19 pm
Location: Lvl 3
Contact:

Re: Stuffs to read before going to bed

Post by MooZ »

A *beep*load of video courses (algebra, calculus, chemistry...) at the Khan academy.
Charles MacDonald
Posts: 38
Joined: Sun Jun 22, 2008 5:18 pm
Contact:

Re: Stuffs to read before going to bed

Post by Charles MacDonald »

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.
Don't forget your two NOPs after CSH.
User avatar
Gravis
Kitten Blaster
Posts: 79
Joined: Sun Jun 22, 2008 3:52 pm
Location: Deadman Wonderland

Re: Stuffs to read before going to bed

Post by Gravis »

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?
1) internal power source.
2) dont use a FPGA
3) use bunny security

Image
User avatar
MooZ
Site Admin
Posts: 407
Joined: Sun Jun 22, 2008 3:19 pm
Location: Lvl 3
Contact:

Re: Stuffs to read before going to bed

Post by MooZ »

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 :)
User avatar
MooZ
Site Admin
Posts: 407
Joined: Sun Jun 22, 2008 3:19 pm
Location: Lvl 3
Contact:

Re: Stuffs to read before going to bed

Post by MooZ »

There were a lot of game source codes released on Romhacking.
Charles MacDonald
Posts: 38
Joined: Sun Jun 22, 2008 5:18 pm
Contact:

Re: Stuffs to read before going to bed

Post by Charles MacDonald »

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.
Don't forget your two NOPs after CSH.
User avatar
MooZ
Site Admin
Posts: 407
Joined: Sun Jun 22, 2008 3:19 pm
Location: Lvl 3
Contact:

Re: Stuffs to read before going to bed

Post by MooZ »

Charles: Cool! They also have it for the Z80, intel 386. And There're a bunch of docs (like schematics for a 6502 tester, assembly books...). You found a gold mine :D

Anyway, PS/2 stuffs: Anyone for a PC-Engine PS/2 keyboard? :)
Charles MacDonald
Posts: 38
Joined: Sun Jun 22, 2008 5:18 pm
Contact:

Re: Stuffs to read before going to bed

Post by Charles MacDonald »

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. :)

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.
User avatar
MooZ
Site Admin
Posts: 407
Joined: Sun Jun 22, 2008 3:19 pm
Location: Lvl 3
Contact:

Re: Stuffs to read before going to bed

Post by MooZ »

So that may explain some weird behaviour on some electronic equipements?

By the way, here's the LM13600/LM13700 story.
Post Reply