secKey

secKey ensures that a URL cannot be changed after it has been generated by the SAP system. This ensures that access to the document is protected and that access protection is managed in the SAP system. The secKey does not protect the document content. The following parameters are always signed (that is, authenticated by means of a digital signature) in secKey:

 

contRep

Content repository

 

accessMode

Access Mode

 

authId

Client ID

 

expiration

Expiry time (UTC)

authId must be a unique identification of the client (such as the SAP system). The UTC expiry time is written in the format yyyymmddhhmmss. If the expiry time is exceeded, the content server must report HTTP status code 401 to the client.

If a secKey is transferred with the URL, the parameters accessMode, authId and expiration must also be transferred. These parameters need not be transferred if secKey is not transferred.

Also, other parameters have to be signed. These additional parameters depend on the particular function and are specified in the function description. The name of the function itself is not signed. The parameters to be signed can appear in the URL in any order. However, the order in which the parameters are transferred to the signing module must be the same as the order in the URL, so that the signature can be authenticated properly.

The secKey for the chosen procedure is about 500 bytes long.

The parameters to be signed for a particular function are specified in the function definition. They are specified in the last column of the parameter table. Optional parameters can clearly only be signed if they are used. s-mandatory parameters must appear in the URL if a signature is used. They are always signed. If no signature is used, these parameters are not evaluated.

The URL parameters to be signed are referred to in this section as the message. The message is used to determine a hash value. The parameters must be kept in the same order so that the hash value can be calculated. The hash or message digest is a one-way function, that is, it cannot be reversed. Using the sender’s private key, the SAP Secure Store & Forward (SSF) module uses the Digital Signature Standard (DSS) to digitally sign the hash value according to PKCS#. The digital signature is transferred in the URL in the parameter secKey, as described above.

Once the digital signature has been created, the URL parameters are protected and cannot be tampered with. They are not encoded and so any receiver can check them using the sender’s public key. Any changes would therefore be detected. This ensures that an action on the content server can only be started if the URL transferred has not been tampered with.

Using the sender public key, the content server generates the Message Digest again from the transferred URL. Likewise, it then forms a hash from the message (the order of the parameters in the URL is important here) and compares the two hashes (the message hash and the hash generated by the sender). If the two hashes match, the URL has been transferred intact between the SAP system and the content server.

The library for checking signatures can be obtained from SAP AG. Because the standard format PKCS#7 was used for the signature, other products can also be used for decoding.

Summary of Technical Information

 

Format of digital signature:

PKCS#7 "signed data"

 

Public key procedure:

DSS

 

Key length:

512 – 1024 bits

 

Public exponent:

216 + 1

 

Public key format:

X.509 v3 certificate

 

MD (message digest) algorithm:

MD5 or RIPEMD-160