The secure communication package of SEMPER provides secure connectivity between modules in separate entities. We intend to keep the design of the package as close as possible to the existing communication package to make migration to secure communications as easy as possible. We provide SecComPoints and SecChannels that look and feel like ComPoints and Channels, but include means for setting security related attributes. Thus the effort of using SecChannels instead of Channels should be minimal. Because of this similarity most parts of the communication package documentation apply also to secure communications.
To achieve better control about the used attributes and addresses we introduce SecComPointAddress which combines a protocol or service module specific address with security attributes. Security attributes are set when creating a SecComPointAddres, so that each existing SecChannel or SecComPoint has a specific set of attributes. In terms of objects, we use the same attributes as the transfer and exchange layer does, see Attribute package of txlayer
As with the communication package, SecComPoint is only an interface. Service modules provide the actual implementation of SecComPoints. Creation of SecComPoints is performed by the SecComPointManager. According to the set security attributes the SecComManager chooses a service module that can provide the desired security mechanisms, and constructs a SecComPoint object.
For more information on the secure communication package, see the document 235UD042, which contains a more general description of architecture and design.
See Attribute package of txlayer
for a detailed description of the used attributes.
The BasicServices service module supports confidentiality and authenticity, see semper.seccomm.basic.html.
The attributes are exchanged between both parties. This means that the attributes that are set when opening a SecComPoint fix the attributes to be used from the peer to the instance that opened the SecComPoint.
A secure address consists of a service specific address (e.g. anonymous addresses will be internally different than normal TCP addresses) and security attributes. Thus all service modules must setup their own addresses by implementing SecComPointAddress.
As with ComPoints, SecComPoints are entities that encapsulate underlying modules. In ComPoints these modules implement communication protocols, in SecComPoint these modules in addition implement cryptographic mechanisms.
The initiator is the module which sends the first message and the responder is the module receiving it. Here is a sample code for the initiator side:
// Create address for responder.
AttributeSet v = new AttributeSet(new Confidentiality("peerID"), new Authenticity("OwnID"));
SecComPointAddress address =
new SecComPointAddress(v);
//Open the server SecComPoint.
server_seccompoint =
SecComManager.secComPoint(SecComPointConstants.SECCOMPOINT_SERVER,
address);
// Create the address to be published.
to_be_published_address = server_seccompoint.getOwnAddress();
// Accept the connection from the initiator, creating the responder
// SecComPoint.
SecComPoint seccompoint = server_seccompoint.accept();
// Receive message. A Message class is not part of the secure
// communication package, basically it can be any Serializable
// object.
Message message = (Message) seccompoint.read();
// Send a response. A Response class is not part of the secure
// communication package, basically it can be any Serializable
// object.
Response response = new Response(...);
seccompoint.write(response);
// Close the responder SecComPoint
seccompoint.close();
// Eventually close the server SecComPoint.
server_seccompoint.close()
The corresponding code for the initiator side:
// Create the address of the initiator
AttributeSet v = new AttributeSet(new Confidentiality("peerID"), new Authenticity("OwnID"));
// The variable published_address contains the address that
// was created by the responder.
SecComPointAddress address = new SecComPointAddress(v,
published_address);
// Open an initiator SecComPoint.
SecComPoint seccompoint =
SecComManager.secComPoint(SecComPointConstants.SECCOMPOINT_INITIATOR,
address);
// Send a message. A Message class is not part of the secure
// communication package, basically it can be any Serializable
// object.
Message message = new Message(...);
seccompoint.write(message);
// Receive a response. A Response class is not part of the secure
// communication package, basically it can be any Serializable
// object.
Response response = (Response) seccompoint.read();
// Close the initiator SecComPoint.
seccompoint.close();
The only sequence constraint between the initiator and responder code executions is that the server SecComPoint must have been opened before the initiator SecComPoint. Message and Response are user defined classes implementing Serializable.
SecChannel widens the communication services of SecComPoint, just as the Channels that are part of the communication package. It allows for multiplexing with a correlator to identify the channel. Additionaly it removes the limitation that the responder must have been opened before the initiator. Here is a sample code for the initiator side:
// Create address for responder
AttributeSet v = new AttributeSet(new Confidentiality("peerID"), new Authenticity("OwnID"));
SecComPointAddress address =
new SecComPointAddress(v);
// Start a service point thread
SecChannelServicePointThread service_point =
SecChannel.startServicePointThread(address);
// Accept the connection from the initiator, creating the responder
// SecComPoint.
SecComPoint seccompoint = service_point.openResponderChannel(correlator);
// Receive message. A Message class is not part of the secure
// communication package, basically it can be any Serializable
// object.
Message message = (Message) seccompoint.read();
// Send a response. A Response class is not part of the secure
// communication package, basically it can be any Serializable
// object.
Response response = new Response(...);
seccompoint.write(response);
// Close the responder SecComPoint.
seccompoint.close();
// Eventually close the server SecComPoint.
service_point.close()
The corresponding code for the initiator side:
// Create the address of the initiator.
AttributeSet v = new AttributeSet(new Confidentiality("peerID"), new Authenticity("OwnID"));
// The variable published_address contains the address that
// was created by the responder.
SecComPointAddress address = new SecComPointAddress(v,
published_address);
// Open an initiator SecComPoint.
SecComPoint seccompoint =
SecChannel.OpenInitiatorChannel(address,correlator);
// Send a message. A Message class is not part of the secure
// communication package, basically it can be any Serializable
// object.
Message message = new Message(...);
seccompoint.write(message);
// Receive a response. A Response class is not part of the secure
// communication package, basically it can be any Serializable
// object.
Response response = (Response) seccompoint.read();
// Close the initiator SecComPoint.
seccompoint.close();
The only sequence constraint between the initiator and responder code executions is that the service-point thread must have been started before the initiator opens the channel.
The following classes implement the SecComPoint API:
The following classes implement the SecChannel API:
For more information, see the document 235UD042, which contains a more general description of architecture and design of the secure communication block.
In order to provide an own service module, implementors have to take the following steps:
You can use SecComPoints and SecChannels. TServerSecChannel.java, TClientSecChannel.java, TClientSecComPoint.java and TServerSecComPoint.java show how to use them. Just type
gmake testin the Test directory to get a small description of how to run the tests.
You have to include the portnumber and the hostname you want to connect to in the SecAddress. The more abstract ways of creating a SecAddress are not implemented yet.
Confidentiality uses symmetric encryption, Integrity uses a MAC. Each object that you write is independently MACed, that should change probably. A serial number (a simple counter on both sides) is added to the sent objects.
To run a rather small test you should: