flexible security 18081

8/13/2019 Flexible Security 18081

1/4

White PaperCryptography & Interoperability

Paul Jackson, Thales e-Security

FLEXIBLE SECURITY

1. ABSTRACTThis 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 previous-

ly unforeseen threat, or perhaps as the result of a more

routine update requirement.

Flexibility is especially important for cryptographic pro-

ducts, 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 flexi-

bility in security systems, and a proposal for achieving it in

hardware-based cryptographic products.

2. KEY WORDSFlexible; Security; Cryptography; Upgrade; Hardware;

Interoperability; Legacy support; Multi-channel; FPGA;

Partial Reconfiguration; Modularity.

3. WHY DO WE NEED FLEXIBLESECURITY?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 secu-

rity 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.1. OBSOLESCENCE OFCRYPTOGRAPHIC

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 crypta-

nalytic success against an a lgorithm 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 algo-

rithm 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, pre-

ferring instead to invest in well-known, but possibly less

secure, alternatives.

3.2. ATTACKSAGAINSTNON-CRYPTOGRAPHIC

ASPECTS OFSECURITY

Cryptographic products now need to provide substan-

tially more than just cryptographic protection. For exam-

ple, 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 commu-

nications protocol itself.

Hacking attacks against non-cryptographic protection

services fall into a similar category to viruses. The anti-virus

August 2003


2/4

3August 2003 August 20032

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 develop-

ments, a facility for regular updates to assure continued

availability of service etc., should exist in cryptographic

products.

3.3. INCREASINGNEED FORINTEROPERABILITY

The need for interoperability between different user

groups is increasing significantly. This is especially proble-

matic for governments, where highly secure information

exchanges between different nations are required to sup-

port dynamic political alliances and military coalitions.

Such interoperability requirements can arrive with little or

no warning. In particular there is often no means of pre-

dicting them at system specification time, s ince 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 require-

ments can often be mutually exclusive. In order that a sin-

gle user does no t 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 interope-

rability 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 gradua l intro-

duction of units that simultaneously offer support for cur-

rent and legacy communication protocols and algorithms

allows a controlled upgrade.

3.4. COMMUNICATIONSINFRASTRUCTURECHANGES

The underlying communications infrastructure over

which a security product operates clearly affects the ope-

ration 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 crypto-

graphic products that operate on them. A lack of available

or upgradable security products can act as a barrier to the

uptake of improved communications capability.

3.5. POORSYSTEMSPECIFICATION

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 miti-

gate the risk that the final system is out-of-date before it is

delivered, he overspecifies the requirements. This over-

specification causes the development to be unnecessarily

complex, increasing the probability that it is late and over-

budget etc.

This is not a problem specific to the security industry,

but the long lead times typically associated with develop-

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 spe-

cification is going to be perfect instead, subsequent

upgrade must be possible.

3.6. GREATERDEPLOYMENT OFCRYPTOGRAPHIC

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 fac-

tors 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

unmanned, inaccessible locations. This raises the need for

a remote upgrade capability.

3.7. DESIGN ORIMPLEMENTATIONERROR

No matter how well-designed and tested a product is, it

will contain errors and while independent security certi-

fication 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, equiva-

lently, 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 pos-

sible, and with the minimum inconvenience to the sys-

tem users.

3.8. RE-USE OF ACOMMONCRYPTOPLATFORM

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, manu-

facture, 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 likeli-

hood, 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.

4. A DESIGN FOR A FLEXIBLE CRYPTOThe 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.

4.1. BASICARCHITECTURE

This suggestion for the development of a flexible hard-

ware cryptographic product starts from a Programmable

Security Module; i.e. a hardware crypto platform with a

Base Kernel operating on it.

As well as comprising the hardware on which the secu-

rity 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 commu-

nications protocol stack to support unit management.

The code-loader in the Base Kernel allows security

applications to be soft loaded onto the Programmable

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 mecha-

nisms, which in turn utilise specific cryptographic algo-

rithms.

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 applica-

tion 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 algo-

rithm, 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

FLEXIBLE SECURITY FLEXIBLE SECURITY

Figure 1 : Vicious Circle of Procurement

Figure 2 : Layers of a Flexible Crypto


3/4

5August 2003 August 20034

4.2. CRYPTOGRAPHICMECHANISMSNEEDED TO

SUPPORTFLEXIBILITY

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 cryptogra-

phic mechanisms caused specifically by the need to

provide flexibility, notably:

4.2.1. Authentication and Integrity of Soft-loaded

Code

In order that an attacker does not simply replace secu-

rity applications or algorithms for ones that offer less or no

security, all code that is loaded must be subject to authen-

tication and integrity verification. In the design proposed

in this White Paper verification is carried out in the code-

loading module in the Base Kernel.

Any number of suitable primitives could be used for this

purpose. Most obviously, a DSA or RSA public key embed-

ded in the Base Kernel would be used to check the signa-

ture 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 crypto-

graphic 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/legacy-

support situations where there is a requirement to offer

multiple algorithms simultaneously, one of which is in theprocess of being replaced. For example, a crypto may

contain both single DES and AES so that it can communi-

cate 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. TECHNOLOGY

Figure 2 illustrates an architecture that is probably not

uncommon in software security products, yet rare in hard-

ware cryptos. Traditionally, the hardware layer of a hard-

ware 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 sys-

tems i.e. the re-programmability of software combined

with the performance of hardware are now well under-

stood. Indeed, FPGA technology is critical to the success of

this design. An ASIC developed to support multiple algo-

rithms (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 ope-

rate at the Gigabit speeds needed for todays communica-

tions requirements, albeit by utilising aggregation tech-

niques. As they become more widely used, there is every

reason to believe that FPGA development will continue to

match the pace of communications technology improve-

ments.

In addition, there are several specific recent advances in

FPGAs that make them especially suitable devices f or flexi-

ble applications:

4.3.1. Partial Reconfiguration

Increasing support in FPGA devices for partial reconfi-

guration 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 usefulwhere applications apply different encryption algorithms

on an on-demand basis.

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-

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 algo-

rithms 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 la st year that sufficiently high-speed interfaces

have been available within the device to support that per-

formance. 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 compo-

nent 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 exe-

cution 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 flexi-

bility through the inclusion of algorithm negotiation, there

are some financial security standards that have just been

revised from only supporting single DES to only suppor-

ting Triple DES.

Module. The Base Kernel API provides the interface spe-

cification 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 pri-

mitives 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.

FLEXIBLE SECURITY FLEXIBLE SECURITY

Figure 4 : Use of Different Cryptographic Algorithms

within an Application

Figure 3 : Supporting Different Security Applications

on the Programmable Security Module


4/4

5. CONCLUSIONThe 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.

FLEXIBLE SECURITY

www.thalesgroup.com/security

flexible security 18081

Documents