White Paper

Cryptography & Interoperability

Paul Jackson, Thales e-Security

FLEXIBLE SECURITY

1. ABSTRACT
This paper discusses the importance of flexible security the capability of a security product or system to be upgraded quickly and cheaply in response to a previously unforeseen threat, or perhaps as the result of a more routine update requirement. Flexibility is especially important for cryptographic products, and most particularly where the application is hardware-based, since generally speaking, these are the systems in which the user has placed the most trust and financial investment. It should be possible to upgrade a crypto unit in a matter of minutes, and this should not require that the unit be physically replaced indeed, in a distributed system, physical access to the unit may be infeasible. The following sections describe the importance of flexibility in security systems, and a proposal for achieving it in hardware-based cryptographic products.

3.1. OBSOLESCENCE OF CRYPTOGRAPHIC ALGORITHMS

Obsolescence may occur as the result of predictable degradation of an algorithms resistance to brute-force attack over time, or due to a sudden, unexpected cryptanalytic success against an algorithm previously considered secure. The need to replace DES has long been appreciated, but even so, in the vast majority of security systems, the cost of upgrade to AES will be enormous, as will the time taken to achieve it. In the financial transactions industry probably the biggest DES user base many systems are still only in the specification stages of a DES to Triple DES upgrade, with AES as yet unplanned for. Furthermore, the rate at which cryptographic algorithms are being replaced is increasing rather than decreasing. The implications of an entirely unexpected flaw being found in a well-established algorithm (the SAFER algorithm range, or AES in five years time, for example) may be extremely serious if no emergency upgrade path is available to systems using it. For this reason, many users and developers are reticent to adopt new algorithms, preferring instead to invest in well-known, but possibly less secure, alternatives.

2. KEY WORDS
Flexible; Security; Cryptography; Upgrade; Hardware; Interoperability; Legacy support; Multi-channel; FPGA; Partial Reconfiguration; Modularity.

3. WHY DO WE NEED FLEXIBLE SECURITY?

There are many circumstances that could trigger the need for upgrade to a security system or product. Some instances are specific to security products; others are more general problems that have particular significance to security systems. Either way, if the system is not sufficiently flexible to allow easy upgrade, the user risks being left with an insecure system, or one that is restricted in the capabilities it provides.

3.2. ATTACKS AGAINST NON-CRYPTOGRAPHIC ASPECTS OF SECURITY

Cryptographic products now need to provide substantially more than just cryptographic protection. For example, in addition to providing data confidentiality through encryption, an IP encryptor is expected to protect against attacks such as denial-of-service that exploit the communications protocol itself. Hacking attacks against non-cryptographic protection services fall into a similar category to viruses. The anti-virus

August 2003

FLEXIBLE SECURITY

FLEXIBLE SECURITY

industry typically releases monthly or quarterly updates for its products, and it is widely accepted that where these updates are not applied, the protection provided is much reduced. Similarly, in the light of new hacking developments, a facility for regular updates to assure continued availability of service etc., should exist in cryptographic products.

or upgradable security products can act as a barrier to the uptake of improved communications capability.

unmanned, inaccessible locations. This raises the need for a remote upgrade capability.

3.5. POOR SYSTEM SPECIFICATION

The traditional procurement cycle for user-specified security systems is extremely unwieldy so much so that some systems take decades to be rolled out. What hope is there then that the specification is correct by the time the system is delivered? A vicious circle develops whereby the customer fears that, in line with previous experience, the system will be late and over-budget. In an attempt to mitigate the risk that the final system is out-of-date before it is delivered, he overspecifies the requirements. This overspecification causes the development to be unnecessarily complex, increasing the probability that it is late and overbudget etc. This is not a problem specific to the security industry, but the long lead times typically associated with develop-

3.7. DESIGN OR IMPLEMENTATION ERROR

No matter how well-designed and tested a product is, it will contain errors and while independent security certification can reduce the number of undetected errors, it does not eliminate them altogether. Again, this problem is by no means unique to the security industry, but the potential impact of errors in security systems (or, equivalently, in safety-critical systems) is very serious. The protection afforded to users information can be jeopardised: either directly, as in the case of early SSL implementations, or indirectly when the error results in product failure, causing the user to abandon the crypto and communicate without security. It is important that where a security system upgrade is required due to implementation error, it can be done as quickly as possible, and with the minimum inconvenience to the system users.

3.3. INCREASING NEED FOR INTEROPERABILITY

The need for interoperability between different user groups is increasing significantly. This is especially problematic for governments, where highly secure information exchanges between different nations are required to support dynamic political alliances and military coalitions. Such interoperability requirements can arrive with little or no warning. In particular there is often no means of predicting them at system specification time, since the events that induce changing political relationships move faster than product specification and development. A flexible security system that can be quickly adapted to utilise an appropriate common security protocol, as required, is one of the best ways of providing support. National and coalition communications security requirements can often be mutually exclusive. In order that a single user does not require separate security devices for each user community he belongs to say, multiple secure radios a single device that can simultaneously support several security protocols is required. In the banking sector, the worldwide trend towards the merging of financial institutions brings with it an interoperability problem: the need to combine or communicate between two separate security systems. In most cases, the inflexibility of the existing systems has meant that the only viable solution is to expand one system to cover the second institution and throw out the other at huge cost. The large investment in security systems also brings with it the need for interoperability between new and legacy cryptographic equipments that could be up to 30 years old. A big-bang upgrade is often infeasible for practical and economic reasons instead the gradual introduction of units that simultaneously offer support for current and legacy communication protocols and algorithms allows a controlled upgrade.

As well as comprising the hardware on which the security application ultimately operates, the hardware crypto platform provides some low-level cryptographic functions such as physical tamper-resistance and random number generation. The Base Kernel consists of a bootstrap, an Operating System, a code-loading module and a communications protocol stack to support unit management. The code-loader in the Base Kernel allows security applications to be soft loaded onto the Programmable

3.8. RE-USE OF A COMMON CRYPTO PLATFORM

Security requirements are becoming increasingly diverse. For cryptographic hardware products, it is not desirable to develop several different platforms to meet them, since this increases the cost of development, manufacture, certification and technical support. Use of multiple platforms does mean that a flaw found in one product is unlikely to manifest itself across a complete product range. However, use of multiple platforms gives an increased risk of a security flaw in any one platform, since the depth of security analysis that can be given to each, in all likelihood, decreases in proportion to the number of platforms supported. The ideal solution is a single platform that supports all requirements, but this necessitates an extremely flexible design that allows different applications and algorithms to be run from a single hardware platform. Figure 2 : Layers of a Flexible Crypto Security Module such applications might include an IP encryptor or a firewall, for example. These are supported by services such as key loading, or key exchange mechanisms, which in turn utilise specific cryptographic algorithms. The code-loader in the Base Kernel is used to load all the security applications, cryptographic support services, and cryptographic algorithms in operation. Notably, an update to the Base Kernel is perceived as just another application an application which, having been loaded, copies itself over the previous Base Kernel, and returns the system to an unconfigured Programmable Security Module. This system may be used to run a single application, or multiple applications simultaneously. Similarly, an application may have a choice of encryption algorithms or key exchange mechanisms available at any time. Where there is only a functional requirement to support a single algorithm, for example, multiple instances of the algorithm can be used to increase throughput or performance. The design clearly relies heavily on a high degree of modularity and re-use. Correctness and clarity of interface specifications are especially important if the full flexibility of the design is to be realised. Figure 3 below illustrates the soft loading of different security applications onto the Programmable Security
August 2003

Figure 1 : Vicious Circle of Procurement ment and certification of security systems compared with the high speed at which communications technology moves mean that it is a serious concern. It is unrealistic to expect that an advanced security system requirements specification is going to be perfect instead, subsequent upgrade must be possible.

4. A DESIGN FOR A FLEXIBLE CRYPTO 3.6. GREATER DEPLOYMENT OF CRYPTOGRAPHIC DEVICES

In general, the size of crypto nets, i.e. the number of communicating units in a system, is increasing over time, as is the number of systems that use cryptography. These factors both lead to an increase in the number of cryptographic devices that are deployed, and by extension the number that would need upgrading in the event of a problem. In addition, as crypto deployments expand, installations become increasingly varied and more units operate from The previous section identifies the need for flexible security systems. What follows is a proposal to support the flexibility requirement in a hardware-based cryptographic product.

3.4. COMMUNICATIONS INFRASTRUCTURE CHANGES

The underlying communications infrastructure over which a security product operates clearly affects the operation of that product. As upgrades to the communications infrastructure are required at an ever increasing rate IPv4 to IPv6, for example so too are upgrades to the cryptographic products that operate on them. A lack of available

4.1. BASIC ARCHITECTURE

This suggestion for the development of a flexible hardware cryptographic product starts from a Programmable Security Module; i.e. a hardware crypto platform with a Base Kernel operating on it.

August 2003

FLEXIBLE SECURITY

FLEXIBLE SECURITY

4.2. CRYPTOGRAPHIC MECHANISMS NEEDED TO SUPPORT FLEXIBILITY

There is a preconception, particularly among the more traditional security-buying communities, that flexibility inherently leads to insecurity and unreliability. This is not the case: obviously a flexible crypto can be insecure or unreliable, just like a conventional fixed crypto, but the provision of flexibility itself should not cause these problems. That said, there are some requirements for cryptographic mechanisms caused specifically by the need to provide flexibility, notably:

4.3. TECHNOLOGY
Figure 2 illustrates an architecture that is probably not uncommon in software security products, yet rare in hardware cryptos. Traditionally, the hardware layer of a hardware crypto might contain an ASIC implementation of an encryption algorithm (DES, say), another ASIC acting as an RSA accelerator, and a microprocessor. The scope for upgrade in this system is limited to those aspects that can be performed by the microprocessor. While changing the encryption algorithm to AES, for example, could be done in a microprocessor, it would be unlikely to provide the performance needed by most applications. A Programmable Security Module would be designed to include generically useful devices whose resources could be utilised by any of the security application or algorithms as needed. The general benefits of using FPGAs in embedded systems i.e. the re-programmability of software combined with the performance of hardware are now well understood. Indeed, FPGA technology is critical to the success of this design. An ASIC developed to support multiple algorithms (or equivalently, multiple ASICs) offers a degree of flexibility, as well as good performance, but only with respect to those requirements that can be predetermined. Many studies have demonstrated that FPGAs are able to operate at the Gigabit speeds needed for todays communications requirements, albeit by utilising aggregation techniques. As they become more widely used, there is every reason to believe that FPGA development will continue to match the pace of communications technology improvements. In addition, there are several specific recent advances in FPGAs that make them especially suitable devices for flexible applications:

Figure 3 : Supporting Different Security Applications on the Programmable Security Module Module. The Base Kernel API provides the interface specification for the security application writers. Note that the soft-loading process could be performed remotely from the crypto over public networks, assuming an appropriate wide-area communications protocol stack IP for example is used in the Base Kernel. This means that inaccessible units can be upgraded without the need to send an operator to the unit to perform the task. Security applications must be written so that they are independent of the cryptographic support services and primitives that they utilise to allow sufficient flexibility. Again this means that the interface between the application and the cryptographic algorithms the algorithm driver must be well-defined.

4.2.1. Authentication and Integrity of Soft-loaded Code

In order that an attacker does not simply replace security applications or algorithms for ones that offer less or no security, all code that is loaded must be subject to authentication and integrity verification. In the design proposed in this White Paper verification is carried out in the codeloading module in the Base Kernel. Any number of suitable primitives could be used for this purpose. Most obviously, a DSA or RSA public key embedded in the Base Kernel would be used to check the signature on (a secure hash of) the loaded code that has been generated using the corresponding secret key. The relative infrequency of soft-loading code decreases the importance of operational performance, thus large key sizes and algorithms generating long hash lengths can be used to provide the necessarily high level of assurance required.

4.2.2. Algorithm Negotiation

Since the design proposed can lead to multiple cryptographic algorithms being available for a specific purpose, it is important that a strong algorithm negotiation protocol is used to pick the best common algorithm shared by the two communicating units. This is particularly important for interoperability/legacysupport situations where there is a requirement to offer multiple algorithms simultaneously, one of which is in the process of being replaced. For example, a crypto may contain both single DES and AES so that it can communicate with legacy devices using DES while system upgrade is carried out, while using AES to communicate with all other devices. There are many means of ensuring that the optimum algorithm is chosen, and that an attacker cannot alter this choice: for example, transmitting and verifying a signed hash of the complete, time-stamped negotiation exchange.

4.3.1. Partial Reconfiguration

Increasing support in FPGA devices for partial reconfiguration i.e. the ability to reconfigure specific logic blocks in isolation, rather than the entire device substantially decreases the time taken to switch between applications and algorithms. This is particularly useful where applications apply different encryption algorithms on an on-demand basis.

ment. In particular, it means that the risk associated with developing a hardware platform and system architecture, in advance of knowing all the application requirements, is substantially reduced. Also, the bus access between the integral processor and the FPGA layer is much faster than could be achieved by an external microprocessor, thereby allowing a more flexible combination of FPGA and microprocessor operations. Increasing Device Size The size of FPGAs has increased in recent years, in terms of both logic blocks and memory available. In just a few years, device size has grown from a point where implementing a single encryption algorithm was difficult, to one where supporting multiple applications or algorithms is straightforward. High Speed Interfaces While FPGAs themselves have been able to support encryption at Gigabit speeds for some time now, it is only within the last year that sufficiently high-speed interfaces have been available within the device to support that performance. Inclusion of Rocket IO technology in the new Virtex Pro series is an example of this. Removing the requirement for an external interface reduces the number of IO pins needed on the device and improves the electromagnetic emanation characteristics of the crypto, since less current is needed to drive internal IO than external IO. The use of FPGAs to provide soft-routing for component connectivity maximises the flexibility of the hardware itself. As an example, a hardware design that connects an FPGA microprocessor core to external RAM for code execution can be replaced by one where external RAM is instead used as a key store for the FPGA encryptor, just by reconfiguring the FPGA image. Traditional hard-routing at board level cannot be changed without building new hardware and this necessitates the physical replacement of old units.

4.4. STANDARDS
Cryptographic product development is generally based on standards, and without flexibility-promoting standards, it is obviously harder to develop a product that is flexible. While most standards bodies recognise the general need for future-proofing in their specifications, there are still some emerging security standards that, for example, provide no capability for changing the cryptographic protocols used. While standards such as IKE provide flexibility through the inclusion of algorithm negotiation, there are some financial security standards that have just been revised from only supporting single DES to only supporting Triple DES.
August 2003

4.3.2. Development of Platform FPGAs

Platform FPGAs incorporate a hard processor core within the FPGA fabric examples include the Xilinx Virtex Pro series, which uses integral PowerPC processors, and the Altera Excalibur devices, which incorporate ARM processors. These allow the software/hardware (FPGA) task-split decision to be taken much later in the develop-

Figure 4 : Use of Different Cryptographic Algorithms within an Application

August 2003

FLEXIBLE SECURITY

5. CONCLUSION
The need for flexible security systems is becoming increasingly important, due to the expense of upgrading traditional systems and the insecurity that can arise from failing to react quickly to new threats. To support this requirement, a layered, modular approach for crypto design is required. A Programmable Security Module could provide sufficient generic resources to support different security applications and algorithms, either simultaneously or as successive upgrades.

www.thalesgroup.com/security