Secure telecommunications using Plasma

What are the basic requirements for secure telecommunications which are, of course, also realized in Plasma? First of all each user trying to establish a secure connection to one or multiple communications partners requires access to his personal security-relevant data. These data are stored in a specially secured area, access to which is possible only using a valid PIN.

Plasma requests this PIN upon establishment of a secure connection from the user. If the PIN entered is correct, the storage area (which can best be thought of as a SmartCard) is opened and the user is then enabled to create a secure communications session; otherwise the establishment process is stopped at this point.

After this access control for the personal security relevant data of the user which in particular contain cryptographic keys it is also necessary for the user to gain certainty about the identity of the communications partner; this requires a mutual authentication of the participating parties in the best case, for which several protocols exist. In Plasma, this is implemented by means of the X.509 authentication protocol [15].

After a successful X.509 three-way-authentication all participants are well informed about the identity of their counterparts: The web server knows which client wants to access his data and conversely the client knows he has contacted the correct web server -- such information is vital, particularly in the case of online transactions and electronic commerce.

During the authentication the security policies, the public asymmetric keys including certificates as well as the session keys which are later used for transferring confidential data are exchanged. The concept of security policies, the exchange thereof in the authentication phase and the subsequent reconciliation of the policies of both communications partners are significant elements of Plasma: an application document is processed by Plasma according to the rules extracted from a Coordinated Security Policy CSP . The CSP is calculated from the security policies (FSPs ) of the communications partners which are exchanged during the authentication phase.

A security policy which yields a relation between the modules medium/structure, cryptographic protocols and security services, thus assigning a cryptographic protocol to a combination of a medium and an activated security service is partitioned into two segments: the profile and the rule part.

The profile part lists the cryptographic protocols available for each security service; this is useful since it may be the case that one of the communicating partners is willing only to communicate if SmartCards are used for storing the cryptographic keys or even that one side wants to exclude a simplistic cryptographic algorithm from the negotiation since it is deemed too insecure by that party.

The rule part lists the specific cryptographic protocols which are to be used when encountering a given media or structural type of an application document in order to provide a requested security service (cf.  Figure , right side).

  

Figure: Relevant modules and a possible security policy

These security policies are created locally at each user's site and must be reconciled prior to the communication proper and immediately after the mutual authentication with communications partner; result is the CSP , mentioned before. To achieve this the set intersection of the profile parts of both policies is generated; in the case of the rule parts the set union is created. This way only such protocols are allowed for the communication which are available on both sides of the communications channel and only those cryptographic protocols are selected which do not contradict any rule from either party.

After a successful authentication of the communications partners the secure communication itself between the participating parties may commence. To achieve secure communications, the security services confidentiality, non-repudiation and integrity are made available by Plasma.

Using Plasma it is now possible to send messages with guaranteed integrity, i.e. the message will arrive provably at the recipient as it has been sent by the sender; non-repudiable message passing means that the sender of the message is uniquely identifiable by the recipient - beyond that the non-repudiation automatically includes the integrity of the transmitted document; lastly, Plasma is capable of generating confidential messages, i.e. messages which only authorized parties - the sender and the recipient - are able to decrypt; all other parties can only access the message in encrypted form.

The concept of security polices and, correspondingly, the media-specific operations which also include the structural properties of an application document are now brought to the fore in the following: the generic security services are activated by default sequentially by Plasma or after explicit user interaction -- only the user may decide at runtime whether a document to be transmitted shall be signed or protected against a loss of confidentiality.

Consequently, a media specific cryptographic protocol matching the activated security service and current media type must be selected which will then be used to meet the security policies' goal. To achieve this, the security policy CSP is queried; this object is structured as a table assigning each media type and generic security service a specific cryptograpic protocol (cf. Figure at the right side).

The result of this query is a cryptographic protocol which is subsequently activated by Plasma. The data are transmitted to this protocol which will then perform the cryptographic operations specific to itself on these data.

Lastly, an integral part of each secure communications session is the ability to dismantle such a connection properly in such a way as to disallow a possible intruder the disruption of such a connection. Therefore this functionality has been integrated into Plasma.

The possibility of user interaction is, similar to the media specific operation on an application document, only possible if the security platform is situated logically close to the application and is capable of communicating with the application. This goal has been reached within Plasma by taking the approach of locating the platform close to the application based on the concept of the GSS-API [9], [17].

An essential feature of any kind of security (in the cryptographical sense) is the need for key management, i.e. the proper administration and storage of the cryptographic keys for each user. Plasma is based on a security technology which implements the cryptograpic algorithms (cf. [7]). The implementation used as a security technology in Plasma is SecuDe (cf. [16]); it is also possible to implement it using a different security technology, for example utilizing the widely spread security package PGP [18].

Therefore the key management of Plasma is fundamentally dependent on the functionality of the underlying security technology. If these security technologies offer key management themselves, Plasma can merely integrate it into itself; otherwise it needs to be modeled within the platform itself; the security technologies PGP and SecuDe for example offer proprietary utilities for certification of their keys and also define the makeup of certified keys and certificates.