JTAG Security

[Michele]

I have been thinking about yesterday's discussion about encrypted and locked-out JTAG sub-systems. I think they can be considered as an "access method" for that subsystem, that need to be communicated by the sub-system and incorporated into the system-level test manager.
This sort of security strategies can be seen as instruments (like in the P1687 terminology) that we need to operate before being able to access the underlying scan chain. At system level we just need to be able to operate them.

IMHO, if we show a way of supporting this authentication through SJTAG, people will stop freezing everything out ! At least everyone but the most paranoids: I heard people actually burning out the JTAG connectors after factory testing...

Michele

[Ian McIntosh]

Mod note: I'm going to move this into a thread of its own - I think this is a topic in its own right.

I agree with Michele's comments here, and feel that the current situation is a simplistic solution brought about by a knee-jerk reaction to what is ultimately a legitimate concern over security.

Anti-tampering should be just that: It should prevent unauthorised re-configuration of the device or retrieval of programmed contents, but should allow legitimate users relatively unhindered access. I say "relatively" because it is perfectly reasonable that some additional task is required to demonstrate authority.

Having said that, for those who really want the ultimate level of device security and genuinely feel they need to completely lock out JTAG, then that should also be possible. Considering the FPGA position we discussed, I don't see why a three-tier scheme can't work using two AT bits, such as this:

Code: Select all

AT1 AT0  Accessibility
0   0    No anti-tamper. Plain bitstream configuration. BScan I/O cells accessible.
0   1    Anti-tamper active. Encrypted bitstream configuration. BScan I/O cells accessible.
1   X    Anti-tamper active. Encrypted bitstream configuration. BScan I/O cells not accessible.

I can't think right now whether the test access should also require the use of an AES encryption key

I guess security needs to be part of the protected device: Adding a "secure gateway" or similar to the chain won't really address the issue for many users (even though it would probably be adequate, even preferable, for my applications), as the JTAG port could be picked-off downstream, although using BGA devices and buried tracking could mitigate that risk to some extent.

[Michele]

I like your scheme, but I would extend it: the authorization mechanism should be able to select which chains are accessible at a given time and which not.
I could, for instance have : a BSCAN I/O scan chain, one or more secure internal chains and one or more non-secure (public) scan chain. The authorization mechanism should enable me to chose to block/open any of the secure scan chain, but it should not impact in any way my access to the public chains.

Brainsotrming out of my head, I can think of the following authorization schemes:

- managed by the JTAG TAP through keys in the IR field;
- managed by some secure gateway inside the JTAG architecture; (the Altera example can be seen in one of these two categories)
- managed internally by each secure device
The latter would be of course the most secure, if even the second could work well if the gateway is strategically placed in some buried or difficult-to-access section of the circuit.

Anyway, I easily see SJTAG supporting all these schemes, and I think we should put some explicit paragraph somewhere in the White Paper about it. People will surely appreciate seeing we are aware of the problem.

[Ian McIntosh]

When I wrote my previous post here, I was specifically thinking about design protection within FPGAs. In that context there are a couple of specific "protections":

• Preventing theft of IP contained within the FPGA. This means that not only must it be difficult to read the FPGAs configuration SRAM, any config PROM/Flash also needs to be obscured, usually through encryption. That encryption is generally adequate protection against most attacks, but obviously the FPGAs own configuration SRAM necessarily holds the data decrypted, so blocking reading of the SRAM by any means (including JTAG) is essential.
• Preventing insertion of malicious code into an device. The use of encryption won't stop someone from loading a bogus image into a config PROM, but it probably prevents it from successfully configuring the FPGA. However, for the malicious, simply achieving non-functionality may be considered "success"
• Prevent unwanted exploration of the design (e.g. reverse engineering the schematics)

The latter probably goes more in the direction that Michele seems to be pointing, i.e. providing security for the design as a whole, rather just the FPGA(s). This could mean that security may need to be part of the gateway, and perhaps on a selective basis.

Personally, my view is that typically there is not too much useful information that can be determined by probing the circuit design via JTAG; the real design content being the code in the programmable devices. For that reason I'm unable to get too excited about board/system level security. Dealing with security at the device level already presents enough challenges. However, my view may be a narrow one and others may be able to present cases to counter my opinion