S 2.163 Determining the factors influencing cryptographic procedures and products

Initiation responsibility: IT Security Management

Implementation responsibility: Administrators; staff responsible for the individual IT applications

Before a decision can be taken as to which cryptographic procedures and products are to be used, details of a number of influencing factors need to be ascertained. The system administrators and staff responsible for the various IT systems and IT applications can be interviewed for this purpose. The results are to be comprehensibly documented.

The following influencing factors must be determined for all storage locations and transmission links specified in S 2.162 Determining the need to use cryptographic procedures and products:

Security aspects

• What are the protection requirements or what security level is it considered necessary to achieve?

• Which cryptographic functions are necessary for this (encryption, protection of integrity, authenticity and/or non-repudiation)?

• Potential of intruders: what type of intruders are to be expected (time available, financial resources, technical skills)?

The answers to these questions are derived from S 2.162 Determining the need to use cryptographic procedures and products.

Technical aspects

Operating heavily branched IT infrastructures with their large numbers of individual components and special equipment (network nodes, servers, databases, etc.) means that security systems must also be heavily branched, with several functional units (security management, security servers, security application components, etc.). Generally speaking the systems have to be examined with a view to not only the functionalities per se but also structural and organisational aspects. It is also necessary to differentiate in respect of the specific technical placement of security components and their integration into non-security components, because this has a direct influence on the implementation of the security functions, on the support required from the operating systems, on expenditure and the cost factor, and not least on the attainable level of security. The geographical localities and the levels of the protocol stack at which the respective security services are implemented and the way in which they are incorporated in the processes of the IT system being protected are quite crucial for the security evaluation. The following questions thus arise:

• Protection offered by the environment: what protection does the environment offer (in terms of infrastructure (access), organisation, staff, technical facilities (protection by operating system, ...))?

• IT system environment: what technology is used, which operating systems, etc.?

• Data volume: what volume of data needs to be protected?

• Frequency: how often is there a requirement for cryptographic services?

• Performance: how fast do cryptographic functions have to operate (off-line, on-line rate)?

Personnel and organisational aspects

• User-friendliness: do users require basic knowledge of cryptography? Does the use of a crypto product hamper them in their work?

• Reasonableness: what burden of extra work can users reasonably be expected to take on (working time, waiting time)?

• Reliability: how reliably will users handle the crypto technology?

• Training requirements: to what extent do users need training?

• Personnel requirements: are additional staff required, for example for installation, operation or key management?

• Availability: is it possible that availability will be reduced by the use of a crypto product?

Economic aspects

• Financial constraints: how much is cryptographic protection allowed to cost? How high are the

- non-recurring investment costs

- running costs, including personnel costs

- licence fees?

• Investment protection: do the planned cryptographic procedures and products conform to existing standards? Are they interoperable with other products?

Key recovery

If the keys used for encryption are lost, this generally also means that the data protected by the keys is also lost. Many crypto products therefore include functions for data recovery in such instances. Before these functions are used, it is important to be clear about the risks involved: if it is possible to restore confidential keys by these means, it must be ensured that this can only be done by those with the appropriate authorisation. If it is possible to access the original key user's data without his or her knowledge, the user has no possibility of proving that malicious manipulation has taken place. On account of the mistrust with which it is viewed, the use of key recovery mechanisms also often results in reservations being expressed within the company or organisation where they are used, but also among communication partners. Generally, therefore, key recovery should not be used in relation to data transmission. There is no need for this, either, because if a key or data is lost, it can simply be sent again. Careful thought should be given to the use of key recovery when data is stored locally (see also S 6.56 Data backup when using cryptographic procedures). The CDROM accompanying the IT Baseline Protection Manual contains an article on the possibilities and risks of key recovery in the Auxiliary Materials directory.

Life span of cryptographic procedures

Cryptographic procedures and products must be checked regularly to establish whether they still represent the state of the art. The algorithms that are used may become too weak as a result of technical developments, such as faster or cheaper IT systems, or because of new mathematical knowledge. The cryptographic products in use may exhibit implementation errors. A time limit for the use of cryptographic procedures should therefore be stipulated at the time of their selection. When the time limit is reached, a thorough review should take place again as to whether the crypto modules in use still offer the expected level of protection.

Legal framework

Various general legal conditions must be observed in relation to the use of cryptographic products. In some countries, for example, cryptographic procedures are not allowed to be used without approval. It is therefore necessary to examine the following points (see S 2.165 Selection of a suitable cryptographic product):

• Whether restrictions on the use of cryptographic products have to be observed in the countries belonging to the area of use (there are no restrictions of any kind within Germany)

• Whether any export restrictions applying to products under consideration have to be observed

However, there are not only maximum requirements applying to the cryptographic algorithms or procedures used, there are also minimum requirements. For example, encryption procedures with a sufficient key length must be used for the transmission of person-related data.

Examples of technical solutions:

In the following there are a number of examples of application relating to the various fields of use for cryptographic procedures. It can be seen that most products cover several fields of use at the same time.

Example 1: Hard disk encryption

The sensitive data stored on the hard disk of a standalone PC needs to be protected in such a way that the following conditions apply:

• The PC can only be booted by authorised users

• Only authorised users are given access to the stored data

• The stored data must be adequately protected against perusal by unauthorised users when the PC is switched off - also in the event of it being stolen.

The foremost priority in this case is the safeguarding of confidentiality. With this in mind, the PC is to be protected against the following threats:

• Unauthorised disclosure of the data stored on the hard disk

• Manipulation of the data stored on the hard disk

• Manipulation of the crypto system

In the event of the PC or hard disk being stolen or lost, the offender has a great deal of time available to gain unauthorised knowledge of the data. A protective measure must guarantee the confidentiality of the stored data even when subject to such extended-length attacks.

The protective measure used should therefore be a product with boot protection and hard disk encryption. Various solutions are available on the market. The choice lies between encryption software (solution A), a hardware encryption component (solution B) or a combination of a hardware component and a software component (solution C). Solution C will typically consist of encryption software in combination with a chip-card reader to provide access control. Which solution is chosen is dependent on various decision criteria:

• Security (crypto algorithm and key length, encryption operating mode, access protection, key generation / distribution/ storage / entry, integration in the operating system, etc.)

Depending on the operating system platform on which encryption is performed, certain limits are inevitably reached with software solutions (solutions A and C). If there cannot be assumed to be a secure operating system with a strict separation of tasks and memory areas (to date, that has not been reliably proved of any operating system), the key used during encryption and decryption must be held unprotected in the memory of the PC for at least a short time. The confidentiality of the key is therefore no longer guaranteed. Hardware encryption components (solution B) may offer more (but not necessarily). The key can be loaded into the hardware component and stored there in a form that secures it against being read out. The key will never leave the hardware component again, and is protected against attempts to search it out. It can only be activated by authorised users with the appropriate ownership and knowledge (e.g. chip card and password). Other aspects are also important, such as the algorithms used for encryption (usually a block encipherment algorithm), their modes of operation (e.g. CBC) and the way in which they are integrated into the PC system. Ideally, the encryption hardware should be integrated in such a way that it compulsorily encrypts the entire hard disk and cannot be deactivated or bypassed by attacks without this being noticed. If contrary to this only individual files are encrypted, there is a risk that the contents of these files may additionally be written to the hard disk in plain text in an uncontrollable manner at least in part (for example to the swap files of various operating systems or to backup files).

• Performance (speed of executable programs)

Software encryption utilises the system resources of the PC; it is therefore a burden on the CPU and uses main memory. At the latest when the entire hard disk is encrypted, the performance of the PC will fall. Hardware components with their own processor may perform encryption without burdening the PC's CPU and consequently without any notable loss of performance. In this respect the throughput rate of the encryption hardware used is one of the crucial factors, depending on the design.

• Organisational/personnel costs (administration, key management, training, etc.)

Expenditure on organisational matters and personnel is dependent on the way the security policy is implemented and on the level of "convenience" of the encryption components. General decision criteria for or against one of the three solutions cannot be formulated with universal validity.

• Economic efficiency (procurement, training/administration costs, ...)

It is difficult to make any general statement about economic efficiency. If only the procurement costs are taken into consideration, software solutions will often be better value than hardware solutions. However, if the losses that can arise as a result of inadequate protection in the longer term are taken into account, investment in more secure and perhaps more expensive solutions may be worthwhile in comparison. Economic disadvantages may accrue in certain circumstances because of performance losses in the PC system.

• Residual risks (operating system, compromising of the hard disk key, etc.)

Consideration of residual risk plays a significant part in the selection of a suitable encryption component. The questions that arise include:

• What residual risks can be considered acceptable?

• What residual risks are or can be minimised by other measures (such as physical or organisational measures)?

It is perfectly possible to obtain several different acceptable solution options by combining various measures.

Example 2: E-mail encryption

The exchange of electronic mail (e-mail) via or within computer networks is becoming ever more important. If this involves exchanging sensitive information (for example company secrets) over unprotected networks, mechanisms to safeguard the confidentiality and/or guarantee the authenticity of messages are required. This is the purpose of email encryption programs. The most widespread of these are two program packages or standards of American origin:

• PGP (Pretty Good Privacy) and

• S/MIME (Secure Multipurpose Internet Mail Extensions)

PGP is a software package that was originally available over the Internet as freeware and has therefore entered widespread use. The S/MIME standard is used in (among others) the secure e-mail applications from Microsoft, Netscape and RSA Data Security Inc.

What does an email encryption program of this type have to do?

The answer is of course dependent to a certain extent on the security measures surrounding it. The requirements are no doubt at their highest when the messages are to be sent via a large, open, insecure network such as the Internet. In this case it may even be that people not known to each other personally want to communicate with each other confidentially and with authentication. What cryptographic services are required in order to be able to do this?

Confidentiality

As the messages are to be encrypted, one or more encryption algorithms must be implemented. On account of the higher performance that they offer, symmetrical procedures tend to suggest themselves.

Key management

• Creation: the keys for the symmetrical procedure must be generated by a suitable (random) process in such a way that guessing or predicting further keys is practically impossible, even if some of the preceding keys are known.

• Key agreement/exchange: as the central provision of keys by means of symmetrical procedures is out of the question in the Internet simply because of the sheer mass of potential communications partners, the use of asymmetrical procedures for key agreement and key exchange is imperative.

Authenticity

As an asymmetrical procedure is implemented anyway because of the requirements relating to key management (and non-repudiation may be required), a digital signature is used for this purpose. Signature keys should be used solely for the purpose of attaching signatures. In this connection, as is always the case when using public key techniques, the problem of the authenticity of public keys has to be solved.

Non-repudiation

Non-repudiation requires a public key infrastructure (PKI: registration of users and certification of public keys by a trustworthy third party, including rules of use). At present, however, there is no such thing as a global PKI, and it is therefore difficult to obtain a non-repudiated proof of origin for e-mails from previously unknown users. In a local network a suitable PKI would have to be created for this purpose.

Conformity with standards

For reasons of interoperability and to protect investment, it makes sense to use Internet standards which are as widespread and broadly accepted as possible. Both S/MIME and PGP are still at the standardisation stage.

Example 3: Secure voice and data communications over ISDN network connections

The following example of application looks at communication via ISDN. The applications to be protected are speech traffic and video conferences, together with data traffic between computer networks. The aim is to ensure the effective protection of confidential information and non-repudiated personal data transferred via the connections. It is assumed that all information that is to be transmitted is available in digital form (PCM code) and that the voice compression commonly used in corporate networks and PBXs can be deactivated for encrypted applications so that the user information channels (B channels) can be encrypted.

To achieve this, an ISDN security component is to be used to protect an S0 connection with two 64 kbit/s channels. It is of no consequence whether individual ISDN terminal devices (telephone, fax, PC with plug-in ISDN card etc.) are connected to the S0 bus or a small PBX is connected on the outgoing side. It should be possible to set up and operate all connections either with encryption or without, as required. The system configuration is shown in the illustration below.

The chosen component is an ISDN crypto device that can be protected against unauthorised use with a chip card. Alternatively there is also a serial V.24 interface available which allows the security component to be configured with the aid of a PC. The user or the end application can control encryption directly with the chip card or by preselection of a special code number. It is also possible to configure the ISDN security component in such a way that certain connections (numbers) are preset as being encrypted or unencrypted. A management station is connected at a central point of the ISDN network for the purpose of key management, i.e. the generation and distribution of key certificates. This ensures that the individual ISDN security components are registered throughout the network and can be supplied with up-to-date key material.

The possibilities available for the secure transfer of information and data worth protecting in an ISDN network are varied and complex. Every relevant basic threat must be met by a specific security measure. In order to guarantee confidentiality, online encryption of the data stream being transferred is most effectively performed on the data link layer. To achieve this, the data is automatically encrypted by crypto hardware before it is transferred, and is decrypted again at the receiving end. Encryption is entirely transparent for the end user and for application programs. The crypto module that is used not only allows real-time processing, it also provides a higher level of protection against attempted attacks in comparison with file encryption (software solution). In order to secure the transmission of data that is binding or subject to proof, it can additionally be assigned a digital signature from the originator. In this way the source and authenticity of the message can be verified by the recipient, and any manipulation that has been carried out in the public network can be reliably detected. To ensure the secure generation and storage of the signature key, use is made once again of the chip card, which is an essential component of the security concept. One extremely important point concerning the connection of computers is the need for appropriate measures to prevent the possibility of inadvertent incorrect switching, which is not usually detected before or during the transmission - in contrast with telephone calls. This can be achieved with built-in firewall functionality in the ISDN security component. With monitoring of the signalling channel (D channel), the security component can be set up in such a way that only explicitly preconfigured crypto connections will be established. In connection with PBXs, there is also provision that certain call numbers and functions can be disabled in the exchanges. This helps to limit the extent to which the vulnerable "remote maintenance" and "call deflection" functions can be exploited.

In order to obtain both secure key management and fast real-time encryption of the user data, hybrid techniques should be used. The method of symmetrical information encryption is retained, while a key known as the session key is exchanged with the aid of an asymmetrical procedure. In practical operation, this proceeds entirely automatically. In this way it is possible to agree new session keys for every new ISDN connection without any significant detriment to operating convenience.

From the security standpoint, the end user should apply the following usage criteria and conditions when selecting and using an ISDN security component:

(Rating: + = important to +++ = very important):

• The individual user keys and authentication information must be stored on a secure medium (e.g. a chip card) and safeguarded with the aid of a trustworthy signature (+++).

• For the purpose of encrypting a communication relationship (voice, data, video, etc.), a new secret key, known as the session key, is to be agreed for each transmission (++).

• The security services are performed automatically and are fully transparent to the end system or end user (+).

• The security component is always set up in crypto mode for selected connections (+++).

• The existing infrastructure should be retained in its entirety when the security components are used (+).

• It should be possible to perform security administration for the security components on a network-wide basis and, if possible, from a central point (+).

• Online operational monitoring and registration of all security components in dialogue with the management station is desirable (+).

The ISDN security components that are selected should have standardised interfaces, should not require any changes in the terminal equipment being protected, and should be easy to integrate into an existing communications environment.