|
|||||||||||||||||||
|
advertisement |
|
|
Protecting the key is the key to secure communications Apr 1, 2008 12:00 PM By Dave Locke Protecting the key against interference or reproduction by the enemy in the event the end system is captured requires security enhancements integrated in the system design that will erase the key in the event of tampering. This article provides an overview of potential security enhancements including the use of volatile memory of the key code and integration of the key code memory within the system electronics to optimize the key protection
Many of us remember the events of April 2001 when a U.S. Navy EP-3E surveillance aircraft was forced to land on Hainan Island off the coast of China after colliding with a Chinese Air Force F-8 interceptor. Whether you believe that this incident was the result of an accident or an intentional act on the part of the Chinese pilot, the unfettered access to an American Naval aircraft with its suite of high-tech surveillance and communications equipment provided China with a wealth of intelligence data. In fact, it has been reported that Japanese defense officials informed the Pentagon that the Link-11 secure military communication system had been compromised and that Tokyo had ordered its defense forces to change Link-11 codes immediately after the EP-3E was captured. The U.S. DoD spends billions each year developing advanced secure communication systems with increasingly complex encryption algorithms. The incident on Hainan Island highlights that even the most complex algorithms are susceptible if an enemy acquires security key codes. What is the best media for storing secure key codes? What are the best techniques for protecting the secure key codes? These are just some of the questions that continue to challenge those entrusted to maintain the security and integrity of U.S. military and intelligence data and systems. Securing key code
Figure 1 is the block diagram of the core to a secure communication-processing system. The complex encryption/decryption engine is typically custom logic implemented with an ASIC or FPGA, or sometimes with a microprocessor using custom software to implement the algorithm. In most cases, the secure key code used by the encryption algorithm is stored in a separate memory off-chip from the encryption engine. There are many practical reasons why this is done yet it makes the effort to protect the secure key code from tampering more complex. To understand why the effort to protect the secure key code from tampering, we must first understand why this memory is not integrated within the encryption engine whether implemented as an ASIC, FPGA or microprocessor. The secure key code must be accessible when system power is on, retained or backed up for long periods when the system power is shut down, and have the ability to be immediately cleared in the event the system is tampered with. Most secure encryption systems will include anti-tampering logic to provide the resources to immediately clear the secure key code if system tampering has been detected. Anti-tampering countermeasures are typically implemented with a layered approach, overlapping and integrating a mix of mechanical and electrical techniques. A variety of storage media can be used for secure key code memory but each has advantages with its own unique anti-tampering challenges. Consider each of the following media. Non-volatile memory, such as flash, EEPROM, CDs or DVDs, is used in some systems for secure key code storage. An example of an encryption engine with non-volatile memory is shown in Figure 2. These systems offer the benefit of being able to retain the secure key code when system power is shut down. Anti-tamper logic has been added to detect if the system has been tampered and to initiate the erase of the secure key code memory. Erasing a non-volatile flash memory or EEPROM in a secure encryption system can be problematic. Using a clear signal on a non-volatile memory may reset the individual bits to a logic ‘0.’ However, the individual memory bits will retain some amount of charge from their previous state even when power is removed. Sophisticated reverse-engineering techniques can be employed to extract the previously stored key code. To ensure that a non-volatile memory has been completely erased, multiple writes of all ‘0’s, all ‘1’s or a checkerboard pattern is performed. This will typically require 20 or more clock cycles and must be able to be done if the system-tampering event includes removal of primary system power. Some amount of power must be retained to power the anti-tamper logic to generate these clock cycles. There are techniques for doing this by retaining charge on a large capacitor, which must then be protected against tampering as well. There is also concern that 20 or more clock cycles are not immediate enough for clearing the memory. Erasing CDs or DVDs also has its own unique set of concerns that must be addressed by the system designer. The CD or DVD can be destroyed with acids or fire but this requires that the threat of tampering is known before it happens and the system operator has sufficient time to destroy the media. For some formats, the media can be erased but some amount of time and power are required. Again, the system operator will need to be aware of the threat of tampering ahead of time and have sufficient time to employ an erase algorithm. Like flash memory or EEPROMs, the erase algorithm must ensure that no residual data is left on the media that would allow reverse engineering techniques to retrieve the data that was stored on the media. FPGA suppliers have touted encrypted configuration file memory as an alternative solution that eliminates the need to include anti-tamper logic. Figure 3 shows a block diagram of this solution that provides the benefit of not requiring a battery back-up and power management circuitry. In this solution, the secure key code is stored as non-volatile memory within the FPGA. The FPGA architecture provides some inherent barriers to reverse engineering. However, the key code is non-volatile and, although the reverse engineering and/or obfuscation barriers are somewhat increased, they are not insurmountable with sufficient resources. |
|
||||||||||||||||
| Back to Top |