In two previous articles, I looked at the JTAG access port from a security perspective, and considered what exposure the choice of BMC operating system might have on a platform supporting At-Scale Debug. Now, let’s consider the root of all trust, the silicon itself, and see what options exist for locking it down.
In Securing JTAG-based At-Scale Debug, I examined the overall attack surface of server Baseboard Management Controllers (BMCs). Since BMCs can be remotely accessed and have privileges in many critical server functions, they absolutely must be secured against execution of malicious code, DoS attacks, and other nefarious measures. Fortunately, this exposure is reasonably well understood, and many of the methodologies as are used within the Intel Management Engine (as documented in Platform Embedded Security Technology Revealed) are employed by server OEMs, server end users, BMC suppliers, and BMC firmware developers. I’d add the usual disclaimer that there is no such thing as a complete secure system, and that security must always take into account prevention as well as detection.
Since insertion of malicious code into an OS kernel is one often-used attack vector, last week I reviewed the Security of BMC Operating Systems next. This article discussed the pros and cons of Linux, WITTENSTEIN OPENRTOS, and Green Hills Software INTEGRITY. Although it’s not clear which OS is the front-runner regarding security, they all claim bulletproof operation, and INTEGRITY appears to be a strong contender amongst proprietary RTOS (although that is of course always open to debate!).
Now, let’s more deeply consider the processor JTAG interface and its vulnerability as an attack surface. As reviewed previously, and from Senrio’s JTAG Explained blog, JTAG access may bestow at least the following privileges:
- Reading and writing from system memory
- Pausing execution of firmware (by setting breakpoints)
- Patching instructions or data in memory
- Injecting instructions directly into the pipeline of the target chip (without modifying memory)
- Extracting firmware (for reverse engineering/vulnerability research)
- Executing private instructions to activate other engines within the chip
The last item is of particular interest. Sometimes, security-related data/functions are hidden behind undocumented instruction encodings. Many JTAG attacks look for such “private” instructions in an 1149.1 implementation. This is relatively easy to do, because the JTAG instruction register has a stated size, and the JTAG documentation (the BSDL file) lists “public” instruction encodings and the size of the instruction register. An attacker only needs to shift in undocumented encodings and pass through UpdateIR (Update Instruction Register) in the 1149.1 state machine to activate undocumented instructions. If the instruction is unused, it generally maps to a BYPASS instruction (where a single shift-capture bit is placed in the TDI-TDO scan path). However, in many cases, undocumented instructions are actually hidden test and debug features, e.g. built-in self test (BIST) modes for memory and I/O; the manufacturing scan and scan compression modes; or debug modes and functions. Some companies, such as Altera with in the Cyclone III Device Handbook, actually list some private instructions and warn that scanning them in may in fact destroy the chip.
For pre-production parts, it seems to be common practice to have the JTAG port be open; that is essential to the performance of early silicon debug functions, manufacturing test, and BIST. For production parts that will deploy to end users, some semiconductor suppliers take the approach of entirely disabling JTAG access. This is often accomplished by fusing off the TMS signal (permanently placing the JTAG finite state-machine in the Test-Logic-Reset state):
But in this instance, all JTAG functions are disabled—even public functions for board test and software development debug functions become unavailable. Because the JTAG port is often necessary for board/system test, debug, and validation, this is unacceptable.
Another approach is as used by NXP, in an example detailed within Configuring Secure JTAG for the i.MX 6 Series Family of Applications Processors. The i.MX 6 series System JTAG Controller (SJC) provides a method of regulating the JTAG access. The three JTAG security modes available are:
- Mode #1—No Debug. This mode provides maximum security. All security-sensitive JTAG features are permanently blocked, preventing any debug.
- Mode #2—Secure JTAG. This mode provides high security. JTAG use is regulated by secret key-based challenge/response authentication mechanism.
- Mode #3—JTAG Enabled. This mode provides low security. This is the default mode of operation for the SJC.
In addition to the three security modes on the i.MX6 , there is an option to disable the SJC functionality entirely. These JTAG modes are configured using One Time Programmable (OTP) eFuses which are burned after packaging. The fuse burning is an irreversible process; once a fuse is burned it is not possible to change the fuse back to the unburned state.
But this is too simplistic. Again, the problem here is, if you turn off JTAG, what happens if you want to turn it on again? Suppose field failures start to emerge on a product line, and JTAG-based debug is the only access mechanism able to triage the problem? How about turning on some embedded tools within the chip, while keeping others secret? It seems that a secure key system, combined with a multi-factor challenge/response, would be one way to “have our cake and eat it too”. In other words, to have a production part naturally be in a “locked” state, and relatively immune to attack, but have some of its instrumentation unlocked in situations where it is critical to have some valuable debug or test engine run for root-cause analysis.
A mechanism for such an implementation has been documented by ASSET and Southern Methodist University within the publication Making it Harder to Unlock an LSIB: Honeytraps and Misdirection in a P1687 Network. Built within the IEEE 1687 “Internal JTAG” (IJTAG) specification is the concept of a variable-length scan chain, necessary to provide standardized access to various (could be hundreds or thousands) of “embedded instruments” within the chip while providing meaningful access times and concurrency. This network of instruments is placed behind segment insertion bits (SIBs) that control access to different scan chains for different instruments:
Our paper proposed a method for hiding instruments in an IEEE 1687 network utilizing a “locking” segment insertion bit (LSIB) that can only be opened when pre-defined values, corresponding to a key, are present in particular bits in the chain:
Also introduced were “trap” bits, that can further reduce the effectiveness of brute force attacks by permanently locking an LSIB when an incorrect value is written to the trap's update register. Only a global reset will then allow the LSIB to become operable again. And finally, IJTAG honeypots make an attacker incorrectly think he or she is making progress.
This is more like it. This is a methodical approach to the security versus debuggability dilemma. As I have said before, obscurity is not a meaningful means to mitigate malicious attacks. I’ll write more on this topic again soon; but in the meantime, to learn more, have a look at our paper above, or read our eBook JTAG | IJTAG Semiconductor and Board Test Security (note: requires registration).
