The Statement Service Block
Author
Introduction
The statement service block provides services for securing information.
The protection offered is:
-
encryption (symmetric and asymmetric),
-
message authentication code (MAC) and
-
digital signatures.
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
-
Statement
-
StatementFile (Statement containing a reference to a file)
-
StatementMemory (Statement, where the message can be represented
by an array of bytes in memory)
-
StatementSerializable (Statements initialised by an arbitrary serializable
object)
-
StatementString (Statement initialise by Strings)
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
-
Making and verifying signatures
-
Making and verifying MAC values
-
Public key encryption/decryption
-
Conventional encryption/decryption
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
-
the hashing algorithm
-
the conventional crypto algorithm
-
the MAC algorithm
-
how conventional keys are encrypted under public keys
In case session keys are exchanged these are maintained in SessionKey,
which has four attributes
-
Conventional encryption key
-
Conventional encryption key
-
Key for MAC generation
-
Key for MAC verification
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
-
the conventional crypto algorithm
-
how conventional keys are encrypted under public keys
As for the occasion that a session for making/verifying signatures only
is opened by calling openSignatureSession,
the class AlgorithmContext
contains information on
-
the hashing algorithm
-
how conventional keys are encrypted under public keys
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:
-
SIMPLE
-
The originator selects a key and sends it cryptographically protected to
the responder.
-
MUTUAL
-
The two parties select a key mutually at random (only computationally random).
See StatementModule
for more information on this method.
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
-
make TStatementMemory (tests StatementMemory)
-
make TStatementString (tests StatementString)
-
make TStatementSerializable (tests StatementSerializable)
-
make TStatementFile (tests StatementFile)
-
make test-server (tests the negotiation of certificates and security algorithms
between a server and a client)
-
make test-client (tests the negotiation of certificates and security algorithms
between a server and a client. You have to start the server first)
-
make test-non-interactive (tests the non-interactive negotiation of certificates
and security algorithms for encryption and making signatures)
-
make test-non-interactive-peer (tests the non-interactive negotiation of
certificates and security algorithms for decryption and verifying signatures.
You have to start the test-non-interactive first)
To be done
-
Improve negotiation
-
Support fault tolerance
-
Access control to the methods must be added. Access control to keys is
handled by the CryptoManager
.