[ISN] Scan design called portal for hackers

[InfoSec News]

http://www.eedesign.com/story/showArticle.jhtml?articleID=51200154

Richard Goering
EE Times 
Oct 25, 2004

Santa Cruz, Calif. -- Think your "smart" credit cards are safe from
hackers, that your company firewall is secure and that no one can
steal the intellectual property in your latest chip design?

Think again. Any chip that uses scan design - and any system built
around it - may be vulnerable to hackers or to other interested third
parties, according to research that will be presented at this week's
International Test Conference in Charlotte, N.C.  
(www.itctestweek.org).

There's a growing recognition in the industry that the very scan
chains that make ICs testable can potentially be used to break their
encryption algorithms and steal their intellectual property.

Opinions differ on how solvable the problem is and on what approach
provides the best possible trade-off between test and security
concerns. An ITC panel scheduled for tomorrow will air different views
on a growing dilemma: that while design-for-test methodologies aim at
making internal IC logic states visible to testers, those very same
features make chips much more vulnerable to hackers.

"Good test quality requires full access to all elements that determine
the internal state of an IC," said Erik Jan Marinessen, principal
scientist at Philips Research Labs in Eindhoven, Netherlands, and
moderator of the Tuesday panel. "Full access means full
controllability and full observability. These test requirements are in
complete contradiction to security requirements, where neither full
controllability nor observability should be given to the world
external to the IC."

Marinessen is optimistic about resolving the dilemma, however. "A
proper control of the IC's life cycle prevents the use of such test
features during application mode when secrets are in use," he said.

But one of the panelists is far more pessimistic. Ramesh Karri,
associate professor of electrical and computing engineering at the
Polytechnic University in Brooklyn, N.Y., is co-author of an ITC paper
titled "Scan-based side channel attack on dedicated hardware
implementations of data encryption standard."

The paper shows how scan chains can be used as a "side channel" to
recover secret keys from a hardware implementation of any
cryptographic algorithm. It details a two-phased attack that can nab a
secret DES encryption key even when the architecture of the scan chain
is unknown and the key is stored in secure memory. A similar paper on
Karri's Web site describes a two-phased attack that can recover AES
encryption keys (see http://cad.poly.edu/encryption).

Karri is a man with a mission. "We want to get to the design and test
communities and tell them that scan is a terrible thing to do," he
said. "Scan is a very bad design-for-test methodology. It is a very
good design-for-hacking methodology."

"It's a real problem," concurred Rohit Kapur, scientist at EDA vendor
Synopsys Inc. Kapur believes, however, that there's a solution, and at
the ITC panel he will propose a scheme that uses decoding and encoding
logic to protect the data in scan chains.

"Scan chains provide a window into the chip," said Yervant Zorian, CTO
of Virage Logic. "But that window can be used off- or online to
extract information from the chip." Like Kapur, Zorian believes one
possible solution is to add encryption and decryption logic to scan
chains.

"It's well known that scan chains are a major source of vulnerability
in embedded systems," said Srinivas Ravi, research staff member at NEC
Laboratories America and a security architect for NEC's
mobile-terminal applications chips. Karri hasn't uncovered a new
problem, Ravi said, but his work is important because it provides a
detailed independent analysis of the issue.

Most ASICs use scan design because it's a relatively easy way to give
testers access to internal states. According to a recent Gartner
Dataquest study, 82 percent of ASIC designers reported that their most
recent designs used scan chain insertion.

The primary alternative is built-in self-test (BIST), which is more
secure because it doesn't require visible scan chains. But BIST is
more complicated to implement and has yet to be widely adopted for
logic. Opinions differ on whether BIST could be an effective
alternative to scan for security-conscious designs.


Trouble with scan

Scan design is based on a relatively simple concept. One or more scan
chains are constructed within a chip by tying together some internal
registers and flip-flops and then connecting them to the serial JTAG
boundary scan interface. During testing, test vectors are scanned in
through the scan input pin, and the contents of internal registers are
scanned out through the scan output pin.

The good news is that automatic test equipment can thus find
stuck-at-1 or stuck-at-0 faults that would otherwise lie hidden within
the device, just waiting to make it fail in the field. The bad news is
that hackers can see the internals of the device too, Karri says.

"By providing a scan chain, you are providing access to the internal
state of a chip," he said. "If you know the algorithm that's being
implemented, any proprietary data that's part of that algorithm can be
easily compromised and discovered."

Thus, said Synopsys' Kapur, "if you have a chip that goes into a
credit card and you are able to scan out information, you might be
able to replicate that card."

Although Karri's paper focuses on a methodology for breaking
encryption algorithms, the problem is far broader, he said: Any kind
of intellectual property can be compromised with scan design.

"Think of a filter with a fancy coefficient that you worked hard to
design," he said. "If you put it into an IC and use scan for testing,
the coefficient can be scanned out. Somebody else can easily come up
with an equally fancy filter based on your IP."

Karri said he wasn't aware of any actual hacker attacks using scan
chains, but he said the security community knows about the problem and
that some of the high-end smart-card vendors are now avoiding scan
chains. He also noted that the Federal Information Processing Standard
(FIPS) for cryptographic modules states that access to the "contents"  
of the module must be restricted. Karri maintains that this
essentially prohibits scan design, even though FIPS does not
explicitly mention it.

Kapur said that a few Synopsys customers who are concerned about
security have said they didn't want to insert scan but that it's not a
"mainstream" concern yet. Thus far the concern is mainly for financial
applications, such as smart credit cards.

NEC's Ravi observed that many smart-card providers disable JTAG
circuitry once the chips are in production. This may not be acceptable
for other kinds of systems, he noted, because debug circuitry is
needed to examine failures in the field.


Countermeasures

Marinessen said providers of security-conscious applications,
including Philips, take "countermeasures" to prevent hacking. But he
declined to comment on the exact nature of those countermeasures.

"I think that in his ITC '04 paper, Professor Karri assumes that it is
relatively easy to find out which IC pins serve as scan chain
inputs/outputs and how the scan operation of the scan chains should be
controlled," Marinessen said. "This is not possible for
state-of-the-art security devices, and hence provides no attack path."

Karri's ITC paper outlines two phases to breaking a DES encryption
algorithm. In the first phase, the paper describes a five-step plan
for applying selected user inputs, or "plaintexts," to determine the
scan chain structure. The paper assumes the hacker has access to
high-level timing diagrams from an ASIC vendor but does not know the
structure of the scan chain.

The second phase shows how a hacker could break the DES algorithm by
applying three known plaintexts. It's an iterative process that
involves four basic steps. Using Mentor Graphics Corp.'s ModelSim
simulator, Karri and his co-authors determined that close to 42,000
clock cycles are required to discover the secret user key.

A hacker would obviously need some knowledge of encryption algorithms
and chip design, but it would not take a lot of sophistication, Karri
said. "It doesn't take a chip designer," he said. "It's quite
straightforward."

Far from being concerned that his paper will encourage hackers, Karri
said that what's important is getting word to the design and test
community, which is largely unaware of the problem.

Karri said he's not optimistic that scan chains can be made more
secure. His paper notes that even when scan chains are unbound after
testing, they can still be accessed by breaking the IC package open.

Kapur of Synopsys, however, believes there is a solution. His idea
involves putting some decoding logic at the scan chain input and
encoding logic at the scan chain output. "As long as the encoding
logic is different from the decoding logic," he said, "what you scan
in, you can't scan out."

This scheme, however, would require support from both scan insertion
tools and from ATE providers, Kapur noted. "The requirement has to get
mainstream for it to take off, but it's all doable," he said.

Karri is skeptical. He said that compression and decompression
circuitry doesn't have security features and can be easily broken. And
he expressed doubt that scan with added encryption and decryption
circuitry would maintain its cost or area advantage over BIST.

Karri believes that BIST offers much more security than scan, but
Kapur termed BIST "low quality" because it requires random patterns
and more test application time. "If you want high quality, you need
deterministic ATPG-based testing, which requires scan," he said.

The real issue, Karri believes, is that design-for-test needs some
fresh thinking. "We need to think outside the box about what might be
a good test methodology," he said. "We have all these great
conferences on DFT and scan. I don't think any of this is correct."