The Statement Service Block

Author


 

Introduction

The statement service block provides services for securing information. The protection offered is: Conventional methods require that the two parties share a key. A key exchange functionality is provided by a module. However, in principle, statements can also be secured using keys shared in other ways. The actual cryptographic operations are supplied by the Crypto Manager. All key material supplied as parameter must be handled using the class CryptoKeyInfo
 

Hierarchy of statements

A statement simply contains the message to be protected as well as the cryptographic information required by the Crypto Manager . In order to support different types of messages the following subclasses of Statement are provided  

Operations on statements

Statements can be operated in two ways. Either directly on the Statement object or by first generating a StatementTransaction object. Operations directly on the Statement requires quite a lot of inputs (e.g., keys). By first establishing a transaction object these keys are fixed as part of the session context. Thus by using the operations this way the interface is quite simple, and in most cases the most convenient way to use statements is to initially set up such a transaction object and use this in all subsequent transfers and exchanges of statements.

In both cases the following operations are available

All of these operations, except the verification of signatures and MACs change the Statement on which they operate. Given a signed or MAC'ed Statement it is possible to recover the Statement, which was originally signed or MACed using the method getPrevious.

The method getPlainText() can be used to retrieve the message which was originally inserted in the Statement. If at some point the Statement was encrypted (and not decrypted again), this method obviously cannot retrieve the message and an exception is thrown.

For more information on the cryptographic services see the cryptographic manager.
 

StatementTransaction

A StatementTransaction object is used to maintain the information needed to exchange secure messages (the context) and it is generated by calling the methods openInitiatorStatementSession or openResponderStatementSession of StatementMan. These methods first negotiate cryptographic algorithms to be used and a method for key exchange.
The class AlgorithmContext contains the agreed information on In case session keys are exchanged these are maintained in SessionKey, which has four attributes Furthermore, a StatementTransaction object is created when opening a one side statement session by calling the methods  openSession or openEncryptionSession or openSignatureSession of  the StatementMan. These methods negotiate cryptographic algorithms according to the kind of session that is opened. When openSession is called the class AlgorithmContext contains information as described above, apart from the MAC algorithm. In the case that a session is opened for encryption/decryption only by calling openEncryptionSession, the class AlgorithmContext contains information on As for the occasion that a session for making/verifying signatures only is opened by calling openSignatureSession, the class AlgorithmContext contains information on Below there is a simple example that describes how a one side Statement session is opened.   First a session for signing and encrypting the statement is created. When the statement is signed and encrypted, a connection is established with the peer and the statement is sent. The peer then, retrieves the certificate used for encrypting the statement and opens a session for decryption and verification of signatures. After the statement is decrypted, the certificate for verifying the signature is available, and the peer verifies the statement's signature.

Key Exchange

If key exchange is requested and the two parties agree on a method for this, a session key is generated afterwards. Key exchange is provided by a module in the state ent block. Currently, only one module exists. This is implemented as part of SEMPER in StatementModule. For the moment only two key exchange protocols are supported:

Use of other Blocks

As mentioned above the Statement Block relies on the Crypto Block for cryptographic services and handling of keys.

It uses the Certificate Block for handling certificates. This is necessary when setting up sessions and when making/verifying signatures.

The Preferences Manager is used for letting the user select cryptographic algorithms. If the user does not make any selections, all supported algorithms are considered to be preferred.

The Archive Manager is used when retrieving keys or when checking the availability of keys. This is done when setting up a statement session.

The Communication Block is also needed for the negotiation of the security algorithms to be used by two peers, as well as for sending/receiving the statement.

Test programs

Eight test programs are provided for testing operations on Statements. To run these go to the test subdirectory and execute

To be done