S 2.163 Determining the factors influencing cryptographic procedures and products

Initiation responsibility: IT Security Officer

Implementation responsibility: Persons responsible for individual applications, Administrator

Before a decision as to which cryptographic procedures and products are to be used can be made, a host of influencing factors must be determined. For this, the system administrators and the persons responsible for the individual IT systems and/or IT applications may be consulted. The results must be clearly documented.

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

Security aspects

• What are the protection requirements and/or which level of security must be attained?
• Which cryptographic functions are required for this (encryption, integrity protection, authenticity, and/or non-repudiation)?
• Attacker potential: Who are the possible attackers (time and financial resources, technical skills)?

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

Technical aspects

Operating widely ramified IT infrastructures with their large number of individual components and special devices (network node, servers, databases, etc.) also requires an widely ramified security system with several functional units (security management, security server, security user components, etc.). Here, system considerations must normally be performed not only addressing the actual functionalities, but also involving structural and organisational aspects. A differentiation should also be made regarding the specific technical location of security components, as well as their integration into non-security components, because this has a direct influence on the implementation of the security functions, the necessary support provided by operating systems, the expenditure, and the cost factor and finally the level of security that can be attained. The question of where (geographic locations) and at which layers of the logging stack the respective security services are implemented and how these are integrated into the processes of the IT system to be protected is very important for the security assessment. This results in the following questions:

• Environmental protection: Which protection is provided by the environment, for example by infrastructural security safeguards such as access control, organisational, personnel, and technical safeguards?
• IT system environment: Which technology, which operating systems, etc., are used?
• Data volume: Which data volume is to be protected?
• Frequency: How often is encryption required?
• Performance: How quickly do cryptographic functions have to work (offline, online rate)?

Personnel and organisational aspects

• User-friendliness: Do the users require basic cryptographic knowledge for operation? Does the use of a cryptographic product interfere with the work?
• Appropriateness: What is the additional workload appropriate for the users (working time, waiting time)?
• Reliability: How reliably will the users use the cryptographic technology?
• Training requirements: How much training will the users need?
• Personnel requirements: Is additional personnel required, e.g. for installation, operation, key management?
• Availability: May the use of a cryptographic product reduce the availability?

Economic aspects

• Financial framework: How much may the cryptographic protection cost? How high are the
  
  • once-off investments,
  • running costs, including personnel costs,
  • license fees?
• Protection of the investment: Are the planned cryptographic procedures and/or products compliant with the existing standards? Are they interoperable with other products?

Key recovery

If the keys used for encryption are lost, the data protected with the help of these keys is also lost, unless the encrypted data is present at a different location additionally. Therefore, many cryptographic products offer data recovery functions for such cases. Before such functions are used, one should also become aware of the risks: If these can be used to restore confidential keys, it must be ensured that this may only be performed by authorised persons. If it is possible to access the data of the owner of the genuine key without this user being aware of the access, this user has no option of providing evidence for malicious manipulations. Due to the mistrust entailed, the use of key recovery mechanisms also often results in reservations within the company and/or government agency, but also on part of the communication partners. Therefore, key recovery should be relinquished in general during data transmission. Furthermore, this is not necessary, since the keys or data can easily be re-exchanged in case they are lost. Therefore, use of this mechanism should be considered carefully when storing data locally (see also S 6.56 Data backup when using cryptographic procedures). An article addressing possibilities and risks of key recovery can be found at Resources for IT-Grundschutz.

Service life of cryptographic procedures

Cryptographic procedures and products must be checked regularly as to whether they still correspond to the state of the art. The algorithms used may become too weak due to new technical developments, e.g. faster, cheaper IT systems, or due to new mathematical findings. The cryptographic products used may be characterised by implementation errors. Therefore, a time limit for the use of cryptographic procedures should already be defined during selection. At this time, it should again be considered carefully whether the encryption modules used still provide the expected protection.

Legal framework

Diverse basic legal conditions must be taken into consideration when using cryptographic products. In some countries, cryptographic procedures may not be used without consent, for example. For this reason, the following must be examined (see S 2.164 Selection of a suitable cryptographic method):

• whether there are restrictions regarding the use of cryptographic products within the countries covered by the field of application (there are no restrictions in Germany) and
• whether there are export restrictions for products coming into question.

However, there are not only maximum requirements, but also minimum requirements regarding the cryptographic algorithms or procedures used. For example, encryption procedures with a sufficient key length must be used when transmitting personal data.

Examples of technical solutions:

Some application examples for the different fields of application for cryptographic procedures can be found below.

Example 1: Hard disk encryption

The sensitive data stored to a memory module, e.g. a hard disk or a flash memory of a stationary or mobile client (such as a PDA, smartphone, tablet, laptop, or PC) must be protected in such a way that

• the computer may only be booted by authorised users,
• only authorised users may access the stored data,
• the stored data is protected against being disclosed to unauthorised persons when the computer is switched off - even in case of theft.

The computer must be protected against the following basic threats:

• unauthorised viewing of the stored data
• manipulation of the stored data
• manipulation of the encryption system

Emphasis should be placed on protecting confidentiality in this case.

If the computer or the memory module is stolen and/or lost, the attacker has large amounts of time to read the data in an unauthorised manner. A protection safeguard must also guarantee the confidentiality of the stored data during such long-term attacks.

Therefore, a product with boot protection and hard disk encryption should be used as protection safeguard. Different solutions are available on the market.

As a matter of principle, an established encryption algorithm (e.g. AES) with a sufficient key length (128 bits at least) should be implemented in a reliable mode of operation (e.g. CBC, OFB, or GCM, no XOR) in the product used.

Either encryption software (solution A), a hardware encryption component (solution B), or a combination of hardware and software component (solution C) may be used. Solution C will typically consist of encryption software in combination with a hardware token, e.g. a chip card or a USB stick, for access control. The solution to be selected depends on different decision criteria:

• Security
  
  Depending on the operating system platform the encryption is operated on, a software solution (solutions A or C) will inevitably be stretched to its limits. If no secure operating system with a strict separation of task and memory area can be assumed (up to now, this has not been proven secure for any operating system!), the key used during encryption and decryption must be stored to the internal memory of the computer in an unprotected manner at least for a short period. This way, the confidentiality of the key may no longer be secured. Hardware encryption components (solution B) may offer more. The key can be loaded to the hardware component and stored there - in a way that it is protected against being read out. The key will not leave the hardware component and is protected against espionage attempts. It may only be enabled by authorised users by means of property and knowledge (e.g. chip card and password). Further aspects such as the method of integration into the computer system are important. Ideally, the encryption should be integrated in such a way that it mandatorily encrypts the entire hard disk and that it cannot be switched off and/or bypassed unobtrusively with the help of attacks If, contrary to the aforementioned, only individual files are encrypted, there is the risk that the contents of these files are at least partially written to the hard disk in clear text in an uncontrolled manner (e.g. in the paging files of different operating systems or in backup files).
• Performance (speed of the executable programs)
  
  Software encryption uses the system resources of the computer, i.e. it loads the CPU and requires internal memory capacity. The performance of the computer may decrease first and foremost when encrypting the entire hard disk. Hardware components with a separate processor may perform the encryption process without loading the CPU and therefore without noteworthy loss of performance. Depending on the design, the transfer rate of the used encryption hardware is also decisive in this regard.
• Organisational and personnel expenditure (administration, key management, training, etc.)
  
  The organisational and/or personnel expenditure depends on the implementation of the security strategy and the convenience of the encryption components. General decision-making criteria in favour of or against one of the three solutions cannot be formulated universally.
• Economy (procurement, training/administration costs, etc.)
  
  It is difficult to make a general statement on economy. If you only consider the procurement costs, software solutions will often be less expensive when compared to hardware solutions. If, on the contrary, the damage that may be caused by poor protection in the long run is also taken into consideration, investing in more secure and maybe more expensive solutions may pay off when compared. Economic disadvantages may be caused by a loss of performance of the computer system.
• Residual risks (operating system, compromising of the hard disk key, etc.)
  
  When selecting the suitable encryption component, the assessment of the residual risk plays a decisive role. The following questions arise, amongst other things:
  • What residual risks can be considered acceptable?
  • What residual risks are or can be minimised by other measures (such as physical or organisational measures)?
  
  
  The combination of different safeguards could well result in several sustainable solutions.

Example 2: Encryption of emails

If sensitive information (e.g. trade secrets) is exchanged using email via unprotected networks, mechanisms for protecting the confidentiality and for guaranteeing the authenticity of messages are necessary.

As a matter of principle, there are two options for protecting the sensitive data.

1. The information to be protected is stored to a file, the file is then encrypted using a file encryption program, and the encrypted file is attached to the email. Here, the actual text of the email remains unprotected.
2. The entire email (text and possible attachments) is encrypted with the help of a specific email encryption program.

Option 2 requires that an email program (e.g. Outlook, Kontact, or Thunderbird) is installed with the user allowing for the integration of an email encryption program as plug-in. If the user uses a web-based email client, only option 1 comes into question.

In this, the prerequisite naturally is that not only the sender of the email, but also the recipient has a compatible encryption program.

Both mentioned options offer end-to-end security between sender and recipient. Here, the sender normally decides which information he/she considers sensitive and worthy of protection. In many cases (depending on the used encryption program), the sender and the recipient are also responsible for key management. The decision as to which data is to be encrypted and key management are taken out of the sender's hands if all emails sent between the sites of an organisation, for example, are generally encrypted and decrypted automatically by the email server. In this case, key management is restricted to the IT administrators of the organisation and the emails are only unprotected between sender and email server and/or email server and recipient, i.e. on routes normally found within a site and therefore in a secure area.

Of course, both methods (end-to-end encryption and automated encryption between the email servers) can be combined with each other, increasing the security this way.

If the emails are protected by means of a file or email encryption program, the selection must be made between a program working with symmetrical mechanisms and a program working with asymmetrical mechanisms (see S 3.23 Introduction to basic cryptographic terms). In any case, a product of a renowned manufacturer should be used working with established and (also for interoperability reasons) standardised procedures. Open source products also often provide a good alternative. Products boastfully advertising "demonstrable 100% security" must usually be treated with caution.

Both types, symmetrical and asymmetrical, have advantages and disadvantages.

Encryption programs with symmetrical mechanisms

For example, a symmetrical mechanism lends itself if sensitive data is to be exchanged within a small working group. The required key can either be generated ad hoc within the framework of a constitutive meeting and distributed to the members - complex key management or even a public key infrastructure (see below) are not necessary. A symmetrical key must in no case be sent via email.

If the key for a symmetrical mechanism is generated manually, i.e. without using a random number generator, it must be taken into consideration that a significantly higher level of security is required for the key when compared to a password for online banking, for example, because there is no erroneous operation counter for the key and an attacker getting hold of an encrypted file has any number of attempts in order to determine the key systematically by using automated procedures.

Some ZIP programs also offer sufficiently secure encryption options, but there are also ZIP programs with poorly implemented or insufficient encryption. Before ZIP programs are used for encrypting confidential information, security management should check the quality of the encryption procedures used and obtain corresponding test reports.

Encryption programs with asymmetric mechanisms

When compared to symmetric encryption, asymmetric encryption provides the advantage that the key used for encryption does not have to be kept a secret. Therefore, an asymmetric procedure is also called public key procedure and the key for encryption is also called "public key". The public keys can be sent via email or published in a directory with a clear conscience. This way, even people who do not know each other personally can communicate confidentially via email.

However, the sender of an email must ensure that the key he/she uses for encrypting the email actually is the public key of the recipient, i.e. that the public key is authentic.

The authenticity of the public keys can be guaranteed by a public key infrastructure (PKI), for example. In a PKI, a trustworthy agency issues certificates for the public keys of the users. The sender of an email would only deem the public key of the recipient trustworthy if it has a valid certificate. The issuing of key certificates by the trustworthy agency may be subject to additional costs.

If there is no PKI or if sender and recipient belong to different PKIs, the sender must ensure the authenticity of the public key by applying different methods. For this, one option is to contact the recipient via telephone and compare the so-called fingerprint of the key (this is a cryptographic hash value of the key). The fingerprint of the public key can be displayed on the screen using the commonly used asymmetric encryption programs. For this, it is necessary that the sender can unambiguously identify the recipient on the telephone (e.g. based on the voice), however.

The following (incompatible) standards are commonly used:

• OpenPGP ("Pretty Good Privacy") and
• S/MIME (Secure Multipurpose Internet Mail Extensions).

For example, OpenPGP is supported by the commercial product PGP and by the open source product GnuPG.

Authenticity of the received email

Symmetrical mechanisms normally offer an implied guarantee regarding the authenticity of the received information, since only the person possessing the key was able to create an email to be reasonably decrypted.

On the contrary, the fact that it was possible to properly decrypt the email does not provide any indication regarding the authenticity of the sender when using an asymmetrical procedure, because the key he/she used for encryption is public, as mentioned. This way, everyone with access to the public key of the recipient may have been the potential sender.

For this reason, asymmetrical procedures provide the sender with the additional option of electronically signing a file and/or an email. In order to check the signature, the recipient needs a public signature key of the sender. (The public signature key should differ from the public encryption key of the sender, if possible. However, signature and encryption key are identical for many products.) In order to verify that the signature key is authentic, a PKI is also needed at this point, or the recipient must compare the fingerprint of the signature key to the sender.

Review questions:

• Were the influencing factors for using cryptographic procedures and products determined and documented?