Chapter 7. Ciphers and cryptographic product considerations

Note



The 40-bit Cryptographic Access Provider (5769-AC1) product and client

encryption product (5769-CE1) used in releases prior to V5R1 are not

supported anymore.



7.1.4 Cryptographic Service Provider, 5722-SS1 Option 35

The Common Cryptographic Architecture Cryptographic Service Provider

(CCA CSP - 5722-SS1 Option 35) must be installed when using the 4758 PCI

Cryptographic Coprocessor for iSeries on the iSeries server, no matter

whether you use the coprocessor for speeding up the SSL handshake or write

your own applications using the APIs provided with this product. In addition

for the cryptographic coprocessor to work, you also need to install one of the

Cryptographic Access Provider products (5722-ACx).



7.1.5 Virtual private networking

OS/400 virtual private networking (VPN) requires you to have one of the

Cryptographic Access Provider products (5722-ACx) installed on the system.

These products determine what encryption and authentication algorithms you

can select in Internet Key Exchange (IKE) policies or data policies when

configuring a VPN connection. Table 15 shows the various supported

algorithms according to the Cryptographic Access Provider products.

When a VPN connection is established, the communication partners verify

each other’s identity. This authentication process, which involves different

kinds of keying material and other variables, is performed during the IKE

exchange. One of the factors that help identify the communication partner is

using information that only the correct partner can know. The information can

be a preshared key or, as introduced with V5R1, RSA signatures using digital

certificates. To use the latter method, the Digital Certificate Manager

(5722-SS1 Option 34) is required to manage the CA trust and the certificates

used for authentication.

If you are doing the VPN processing on communications equipment, such as

a router, then the iSeries 400 or AS/400 server encryption is not involved.



7.1.6 Cryptographic Support for AS/400, 5722-CR1

This product was initially introduced to the AS/400 server when there were no

hardware cryptographic adapters available on the system. It supports data

encryption and decryption, Message Authentication Code (MAC) generation



374



iSeries Wired Network Security



and verification, key management, and Personal Identification Number (PIN)

management. It was primarily aimed to provide cryptography support that

was compatible with 4700 Finance Communications Subsystems.

All functions supported by this program product can also be performed on an

4758 PCI Cryptographic Coprocessor for iSeries. However, the cryptographic

coprocessor supports many more functions than the 5722-CR1 product

supports.

If you do not have existing applications that use the 5722-CR1 product, you

should consider using the 4758 PCI Cryptographic Coprocessor for iSeries

for developing new applications.



7.1.7 Key sizes

The supported key sizes for the different protocols and program products

depend on the installed Cryptographic Access Provider product. Table 15

shows the characteristics of the available Cryptographic Access Provider

products on the iSeries 400 or AS/400 server.

Table 15. Supported algorithms



Algorithm



5722-AC2



5722-AC3



Notes



Hash/Authentication algorithms

MD5



Supported



Supported



SHA-1



Supported



Supported



Encryption algorithms (symmetric)

CDMF



40-bit



40-bit



2



DES



56-bit



56-bit



3-DES



Not supported



168-bit



6



RC2



56-bit



128-bit/1024-bit



3, 7



RC4



56-bit



128-bit/2048-bit



4, 7



RC5



56-bit



128-bit



5, 7



AES



56-bit



128-bit



5, 7



SEAL



Not supported



256-bit



8



MARS



56-bit



160-bit



8



Blowfish



56-bit



448-bit



8



Chapter 7. Ciphers and cryptographic product considerations



375



Algorithm



5722-AC2



5722-AC3



Notes



DESX



Not supported



64-bit



5, 7



Encryption algorithms (asymmetric)

RSA



1024-bit



2048-bit



9



DSA



1024-bit



1024-bit



7, 9



Diffie-Hellman



1024-bit



1024-bit



7, 9



Notes:

1.

2.



The Common Data Masking Facility (CDMF) algorithm is supported only on the

4758 Cryptographic Coprocessor.



3.



The RC2 encryption algorithm with the 5722-AC3 CAP product supports

1024-bit only when using the Java Development Kit (JDK), (5722-JV1) to

access cryptography functions of the Java Cryptography Extensions (JCE). The

JCE 1.2 is a standard extension to the Java 2 Software Development Kit

(J2SDK), Standard Edition. The JCE implementation on iSeries 400 is

compatible with the implementation of Sun Microsystems, Inc.



4.



The RC4 encryption algorithm with the 5722-AC3 CAP product supports

2048-bit only when using the Java Development Kit (JDK), (5722-JV1) to

access cryptography functions of the Java Cryptography Extensions (JCE). The

JCE 1.2 is a standard extension to the Java 2 Software Development Kit

(J2SDK), Standard Edition. The JCE implementation on iSeries 400 is

compatible with the implementation of Sun Microsystems, Inc.



5.



Algorithm is not supported by JCE 1.2.



6.



The Triple-DES cipher is sometimes described as having a key length of 168

bits. However it is actually a 56-bit cipher performed three times, and is not as

strong as some of the 128-bit ciphers such as AES. When we talk of 128-bit

ciphers and key lengths up to 128 bits, we include Triple-DES. The 4758

Cryptographic Coprocessor supports 112-bit Triple-DES.



7.



Algorithm is not supported by the 4758 PCI Cryptographic Coprocessor for

iSeries.



8.



Algorithm is supported only with the Java Cryptography Extensions (JCE) 1.2.

For more information about JCE refer to Java Cryptography Extensions found in

the iSeries Information Center by clicking Programming->Java->IBM

Developer Kit for Java->Security->Java Cryptography Extensions.



9.



376



The Cryptographic Access Provider product 57xx-AC1 is no longer supported in

OS/400 V5R1.



The key size limitations for the public key algorithms (RSA, DSA, and

Diffie/Hellman) apply to the generation of public/private key pairs. No

restrictions are ever placed on the public key size when verifying a digital

signature.



iSeries Wired Network Security



7.1.8 Export restrictions

Export regulations used to prohibit the export of strong encryption products

from many countries. Since January 2000 when the US government relaxed

the export regulations of cryptography products, most countries are now party

to the Wassenaar Arrangement and allow the export of any encryption

product to anywhere except for a few defined countries. For example, the

USA forbids export to Cuba. However government rules and regulations keep

changing, so in case of doubt, check first.

Due to the previous export restrictions there are still a lot of applications,

primarily older Internet browsers, that can only do weak encryption with 56 or

40-bit keys. This may be of concern with some applications.



7.2 Upgrading to a different Cryptographic Access Provider product

If you currently have the 56-bit Cryptographic Access Provider (5722-AC2)

product installed, and you install the 128-bit version (5722-AC3) to replace it,

you must IPL your system before the change takes effect. Note that you can

only have one 5722-ACx product installed at a time on the system, but you

can install one or more client encryption (5722-CEx) products on a single

system. To update a client encryption product in Client Access on a PC, you

need to install the new SSL option by running the Selective Setup, with the

/QIBM directory specified as the installation source directory. The setup

program will remove the existing client encryption version first and then will

install the new version.

Note



If the new client encryption product (for example, SSL Client Encryption

128-bit) is not displayed in the list of installable products, you need to

check that the directory path in the IFS has the proper authority settings.

By default, the public authority for all client encryption products is set to

*EXCLUDE. If you want administrators or users to install a client encryption

product on their PCs, you need to grant *RX authority to the product

directory:

5722-CE2 56-bit



/qibm/proddata/CA400/Express/SSL/SSL56



5722-CE3 128-bit



/qibm/proddata/CA400/Express/SSL/SSL128



If you are also using the 4758 PCI Cryptographic Coprocessor for iSeries and

want to upgrade the Cryptographic Access Provider product, you need to

reload the function control vector (FCV). The FCV is a digitally signed value



Chapter 7. Ciphers and cryptographic product considerations



377



stored in a file provided by IBM used by the cryptographic coprocessor to

determine what type of cryptographic functions and algorithms the

coprocessor supports. To update the FCV, you have to use the 4758

Cryptographic Coprocessor configuration utility from the AS/400 Tasks page

or the Cryptographic_Facility_Control (CSUACFC) API when writing your own

application. When using the graphical browser-based interface, select

Manage Configuration ->Attributes, then select the desired processor and

load the new FCV.



7.3 Key length considerations

This section discusses why a number of key lengths exist and how to go

about choosing the most appropriate size for your intended functions.



7.3.1 Certificate keys

Certificates use public/private keys. Public/private keys are a pair of

mathematically related numbers that can be used so that data encrypted with

one key can only be decrypted by the other. The public key can be published

so that anyone can use it without compromising the security of the system.

Part of a certificate is a public key. This can be used to encrypt data to be

sent to the certificate owner, who in turn uses the corresponding private key

to decrypt the data. It can also be used to decrypt data sent from the key

owner, encrypted with the private key, for example to verify an object

signature. The private key is, or should be, held in a secure place by the

certificate owner.

A key pair is generated from the product of two large prime numbers; their

security is directly related to the difficulty of determining the original primes

from the product. Increasing the size of the numbers involved makes the task

of determining the original primes much more difficult. A key length of 1024

bits is much harder to break than one of 512.

According to RSA Laboratories, a 512-bit key can currently be factored in a

few months, and so should only be used for data that needs to be kept secure

for a short period. RSA recommends 1024-bit keys for most uses and

2048-bit keys for securing extremely sensitive data such as the root key pair

for a Certificate Authority. They say 768-bit keys are still secure and may be

used for less valuable information.

Because the public/private key pair associated with a certificate is used for

the life of the certificate, they must be very secure. If your data is valuable, it

may be worthwhile for someone to invest some months of machine time to



378



iSeries Wired Network Security



break your keys. If you want to keep data secure for a long period, you must

consider how secure your keys are likely to be at the end of that period. This

is the reason for RSA recommending a key length of 1024 instead of 768.

Public/private keys have to be large enough so that it is not feasible to

calculate the private key from the public key. This results in key sizes that are

much larger than necessary for data encryption. If you use encryption a lot,

the processing time taken may be significant. RSA Laboratories says that

doubling the length of your keys will, on average, increase the time for public

key operations by a factor of 4 and the time for private key operations by a

factor of eight. When you renew your certificates, you should consider the key

length to use. RSA Laboratories publishes its recommended key lengths on a

regular basis. Refer to the URL

http://www.rsasecurity.com/rsalabs/faq/3-1-5.html to read the article in

RSA’s FAQ Section 3.1.5, "How large a key should be used in the RSA

cryptosystem?”

Public/private keys (asymmetric keys) are generally used for signing, verifying

signatures, authentication, encrypting documents, and initiating secured

communications such as SSL. They are not usually used for encrypting large

amounts of data or for secured communications. The reason is the time taken

for encryption and decrypting would be too long. Instead they are used to

enable a secret key to be passed between the parties. The secret key

(symmetric key) is then used for subsequent encryption and decryption.



7.3.2 SSL session keys

A secret key is used to secure SSL communication sessions. This is

negotiated during the SSL handshake by the client. The client generates the

secret key, uses the server certificate’s public key to encrypt it, and sends it

to the server. Then the server decrypts the encrypted secret key using its

private key. Henceforth the secret key is used for encryption and decryption

by both client and server.

Because the key is secret, the only issues are the security of encrypted data,

and the time needed for encryption and decryption processing. Ciphers

based on secret keys are chosen to give good security while requiring little

time to perform encryption and decryption. They are much faster to use than

public/private key pairs.

The time required to break SSL keys by one estimate are shown in Table 16

on page 380.



Chapter 7. Ciphers and cryptographic product considerations



379



Table 16. Time required to break SSL keys



Key length

in bits



1995



2000



2005



40



1.07 hours



8.6 minutes



68 seconds



56



7.4 weeks



6.5 days



19 hours



64



36.7 years



4.6 years



6.9 months



128



6.7e17 millennia



8.4e16 millennia



1.1e16 millenia



The numbers are very approximate, but this gives an idea of the relative

security of the different key lengths. The article containing this table can be

found at http://www.tml.hut.fi/Studies/Tik-110.350/1998/Essays/ssl.html



7.4 SSL ciphers

There are many ciphers that can be used for SSL processing. During the

handshake the server and client attempt to find the best cipher they can both

use. If this fails, the SSL session will not start. Both server and client may

have a list of ciphers they can use. The lists are in order of most preferred to

least preferred. During the SSL handshake, the client presents its list to the

server and the server chooses the cipher to use - if there is at least one

match.

For some SSL-enabled applications on the iSeries and AS/400 servers, you

can select the ciphers you want the application to support, which includes

sockets applications written with the Global Secure Toolkit (GSKit) or the

HTTP Server.

In the following lists the first term in the cipher description refers to the

encryption method, for example RC4. The second refers to the authentication

method, for example SHA. Last is a note about where the cipher was allowed

to be used and the key size. Note that the information about where a cipher

can be used can change due to government regulations.

For SSL Version 3 and TLS Version 1 the ciphers supported are shown in

Table 17.



380



iSeries Wired Network Security



Table 17. Supported ciphers in TLS V1 and SSL V3



Cipher suite



Encryption



Hash



Encryption key length



0001



Null



MD5



This performs authentication only



0002



Null



SHA



This performs authentication only



0003



RC4



MD5



Export (40-bit)



0004



RC4



MD5



US (128-bit)



0005



RC4



SHA



US (128-bit)



0006



RC2



MD5



Export (40-bit)



0009



DES



SHA



Export (56-bit)



000A



Triple-DES



SHA



US (168-bit)



002F



AES



SHA



US (128-bit)



For SSL Version 2, the ciphers supported are shown in Table 18.

Table 18. Supported ciphers in SSL V2



Cipher suite



Encryption



Encryption key length



1



RC4



US (128-bit)



2



RC4



Export (40-bit)



3



RC2



US (128-bit)



4



RC2



Export (40-bit)



6



DES



(56-bit)



7



Triple-DES



US (168-bit)



Note



The previous listing contains all the supported ciphers for the protocols

specified on the iSeries and AS/400 server. The actual ciphers available for

use depend on the installed Cryptographic Access Provider (CAP) product.

Refer to Table 15 on page 375 for information about the ciphers supported

in the different CAPs. Note that the iSeries and AS/400 server support

three additional cipher suites for TLS V1 and SSL V3 (first byte contains

FF) that are considered proprietary. For more information about the

additional cipher suites refer to the SSL_Init() API documentation in the

iSeries Information Center.



Chapter 7. Ciphers and cryptographic product considerations



381



7.5 Controlling and determining the protocol and cipher used

Three versions of SSL, or protocols, are in use. SSL V2 and SSL V3 are

standards published by Netscape. TLS V1 is an RFC (RFC2246) published

and administered as are the other Internet standards.

SSL V2 is old and not often used now. It does not support client

authentication and has a number of known security weaknesses. SSL V3 is

significantly different from SSL V2 and is now the protocol most commonly

used. TLS V1 is a new protocol, very similar to SSL V3, that addresses some

security and performance issues discovered in SSL V3.

Both the SSL clients and servers have a list of ciphers, known as the cipher

suite list, they are willing to use. During the SSL handshake, the lists are

compared and a cipher, normally the strongest, is chosen.

This section discusses how you can work with protocols, cipher suite lists,

and ciphers.



7.5.1 SSL applications on the iSeries 400 and AS/400 servers

Applications you create on the system can use the GSK APIs

gsk_attribute_set_buffer and gsk_attribute_set_enum to specify the SSL

protocols they support and the cipher suite list to be used.

If you are writing both the server and client parts of an application you may

choose to use only TLS V1 and one cipher. If you are working with the public,

or a number of other companies, you would probably support at least SSL V3

and TLS V1, and you would use a list of all the ciphers that are acceptable to

you, in order of strongest to weakest.

SSL applications will negotiate a common protocol if they can. A server that

supports TLS V1, SSL V3, and SSL V2 can communicate with clients using

any of these protocols. A client supporting TLS V1 and SSL V3 can

communicate with a server that support either SSL V3 or TLS V1. The only

thing that does not work is a server supporting only SSL V2.

Applications can use the GSK API gsk_attribute_get_buffer with identifiers

207 and 208 to determine the cipher and the SSL protocol used for the

current connection. To determine the cipher used from outside the SSL

application would not be easy; a trace of the handshake communications and

a detailed knowledge of the protocols would be required.



382



iSeries Wired Network Security



7.5.2 Default cipher suite lists

The default cipher list for SSL V3 and TLS V1 is 04050A090306 if the 128-bit

Cryptographic Access Provider product is installed; otherwise the list is

090306.

Note



At the time this redbook was written, the V5R1 documentation stated the

default list will be 2F04050A090306, that is, AES is the preferred cipher.

However, IBM has decided to exclude AES from the default list until other

vendors have implemented it and IBM has verified that there are no

interoperability problems. When this has been done, IBM will change

OS/400 to make AES the preferred cipher.

You can still use AES if you want, by specifying a cipher suite list that

includes it.



For SSL V2, the default list is 136724 if the 128-bit Cryptographic Access

Provider product is installed; otherwise the list is 624.

To ensure the cipher suite list your application uses, only include ciphers

acceptable to you; if it is strong enough to adequately secure your data, then

the cipher used is of little interest. However, you may choose to accept weak

ciphers so your application can work with older browsers. In this case you

may want to take some action, such as issuing a warning, if a weak cipher or

protocol is being used.



7.5.3 Using SSL with Web browsers

If you are using a Web browser, you may be interested to know what cipher is

being used, particularly if what you are doing is sensitive to you.

• Until recently the US government regulations prohibited export of

browsers, capable of strong encryption, outside of the USA and Canada.

• Older browsers may only support weak encryption.

There are several ways of determining what cipher is used for a specific

connection. One Web site we found displays the cipher you negotiate with it

and can be used to determine the strongest cipher the browser supports. The

URL is http://www.fortify.net/sslcheck.html



Chapter 7. Ciphers and cryptographic product considerations



383



If you want to determine what cipher is used for a specific SSL connection,

you can also display the connection properties as documented in the

following examples.

7.5.3.1 Determining the used cipher with Internet Explorer 5.0

With Microsoft’s Internet Explorer 5.0 you can hover the cursor over the

padlock icon to display the SSL key length as shown in Figure 285.



Figure 285. Microsoft Internet Explorer 5.0 - encryption key length



To obtain more details about the SSL session properties, click File ->

Properties to display the connection details as shown in Figure 286.



Figure 286. Microsoft Internet Explorer 5.0 SSL Properties display



The connection properties shown in Figure 286 indicate that the TLS V1

protocol with the RC4 encryption algorithm and a key length of 128 bits is

used. It also states that the certificate used for authentication has a public

key length of 1024 bits.



384



iSeries Wired Network Security