[LINK] Backdoor found in Chinese made chip
Glen Turner
gdt at gdt.id.au
Wed May 30 10:26:58 AEST 2012
On 29/05/12 19:28, Rachel Polanskis wrote:
> So why was the fact the "chip" was in fact an FPGA not mentioned in the media?
Because it makes no real difference to the threat. Remember that this
isn't a backdoor inserted by the FPGA programmer, but one inherent in
the FPGA itself, whatever software is loaded. Being able to download
another program isn't a huge exposure of itself, but could certainly be
extraordinarily useful in a system-wide subversive design (ie, a machine
which behaves as normal through all testing and inspection).
> Apparently the "hole" is only uncovered by some custom software you can only get
> from the person who "found" it.
As you would expect: if there's a commercial product which you are using
as its manufacturer intended, then it isn't research. Doubtless a
peer-reviewed paper will be published in a year or three.
The question which is harder to answer is intent. All complex ASICs
contain backdoors for system testing. For example, it is difficult to
test items such as CPU L2 and L3 caches without them -- there are no
off-chip signals and timing is difficult to measure from a CPU program.
These features are usually activated by writing to hidden registers and
commands only take effect after some key sequence is given. The quality
of the cryptographic design of these systems varies considerably: for
CPU manufacturers paranoia is the norm -- they don't want random code to
spring the lock, especially since some test commands will be destructive
in an installed chip; manufacturers of other chip types are less
concerned (eg, one modem manufacturer documents the address of the test
register and tells programmers not to use it).
You've also got to bear in mind which sort of cryptosystems use FPGAs.
The highest levels of assurance have strong traceability: not only must
all requirements be traced to functions which implement them, but all
functions must be traced back to requirements. No unrequired functions
are permitted. This traceability excludes general purpose CPUs and
FPGAs, which is why cryptographic equipment for connecting high
classification networks to low classification networks costs a small
fortune.
It's the next level of interconnect which is the issue: devices which
connect medium classification to low classification networks only need
to demonstrate requirement-->function traceability. Thus they can use
general purpose CPUs and FPGAs.
I have some serious issues with the design of that FPGA. Accepting a
diagnostic command without an exterior pin being held at a diagnostic
voltage is very poor design. To what extent that design is the result of
direction from the state is impossible to say. In that sense this
research doesn't answer the essential question.
Finally, note that the technology used to discover this has wide
application. It's the death of on-chip DRM schemes. Smart cards and prox
cards are already pretty well compromised at a hardware level, and this
certainly isn't going to help.
--
Glen Turner www.gdt.id.au/~gdt
More information about the Link
mailing list