Table of Contents
All communication between habitats must be done over a network. The ARE can use JXTA, a peer to peer library, as its primary communication layer. This section describes the security aspects of the JXTA layer as implemented in the default JXTA messenger plugin.
- Advertisement
An XML document by which a Habitat advertises its properties in a JXTA network.
- Certificate
Datastructure containing public key and identity information which is signed by a Certificate Authority. Note that the certificate as used by JXTA is a different thing altogether than the certificate an agent developer can use to sign his dna files.
- Certificate Authority
A party that issues certificates.
- Habitat keypair
A private key and a certificate containing the public key by which habitats identify themselves and by which they can be authenticated.
- JXTA
A set of protocols for peer to peer networks. The JXTA documentation can be found at their website [JXTA].
- Relay
An Habitat that can also be used to connect isolated subnets.
- TLS
Transport Layer Security, also known as SSLv3. Tryllian uses TLS to create secure communication channels between peers over JXTA. It is described in [RFC2246].
In order to exchange messages, JXTA based Habitats use the following steps:
Use the peer discovery protocol to obtain the Advertisement of the other Habitat.
Use this Advertisement to create a Pipe to the other Habitat.
Send a message through the Pipe.
Secure Habitat Communication refers to protecting these steps from malicious entities using standard cryptographic techniques. The ARE uses X.509 certificates for authentication (see below); the trust model is based on the concept of Certificate Authorities (CAs) and follows the TLS specification.
Note
Agent signing is not related to Secure Habitat Communication; instead, agent signing is used to assign permissions to agents once they have arrived at a Habitat.
Broadly, the process works as follows. Habitats are conceptually grouped by a CA. The CA issues a certificate for every Habitat it trusts. Then Habitats include this certificate in their Advertisement.
When a Habitat initiates a connection to another Habitat, both Habitats authenticate each other by checking the certificates. If the certificate is signed by a trusted CA, the connection is accepted. At that point, the TLS connection is set up and the message is transferred.
The secure connection uses the TLS protocol [8]. The TLS protocol is implemented on top of the JXTA connections; this allows for secure connections that are routed through firewalls and other Habitats. JXTA reuses TLS connections between peers, avoiding the complex security handshake procedure.
TLS defines many cipher suites; the following suites are supported by the ADK:
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
The cipher suite actually used is determined by the ADK.
In order to provide an easy key infrastructure, Tryllian uses X.509 certificates for all key-related activities. More specifically, Tryllian uses version 3 of Internet X.509 Public Key Infrastructure Certificate and CRL Profile which allows applications to define their own extensions, thus enhancing the expressive power of the certificate.
All extensions defined by Tryllian are derived from Tryllian's Private Enterprise Code, a number issued by the Internet Assigned Numbers Association. The number assigned to Tryllian is 1.3.6.1.4.1.9727 ([PEN])
JXTA uses the concept of Peergroups to reduce the number of peers visible to other peers. Habitats are always member of the Tryllian Peergroup. Although JXTA theoretically supports Secure Peergroups, the current implementation is not yet fit for our purposes.
This means that Habitats on the network will always be visible to all other Habitats sharing the same network (either physical network or multiple networks connected by relays). However, this does not imply that every Habitat will be able to connect to other Habitats; connections will only be made between Habitats that trust each other.
In order to secure something, it is necessary to know what attacks are possible. This section describes the attacks that can be imagined, and how this can be prevented.
| Attack | Prevention |
|---|---|
| Eavesdropping | Since the connection is encrypted, eavesdropping is prevented [9]. |
| Impostor | TLS ensures that the certificate used by a Habitat is indeed owned by that Habitat. |
| Data integrity | Data integrity is safeguarded by the TLS connection. Any modified data will be detected, since with each TLS data packet a secure digest is included. |
| Man-in-the-middle | In the current implementation, certificates advertisements are not signed. This is a known shortcoming, and the JXTA development team is working on it[10]. Until that time, relaying Habitats can perform man-in-the-middle attacks. |
| Replay attack | Replay attack is not posible, since each TLS sessions uses unique session keys that are generated by a secure random generator. |
Note
The man-in-the-middle attack can be solved by signing and verifying (part of) the advertisement.
The trust model is based on the notion of Certificate Authorities. Trust is two-valued: you trust someone or you don't. Here we define trust between Habitats. How a Habitat trusts an Agent is defined by the Habitat's role definitions. All other cases of trust relationships are not defined.
Each Habitat is equipped with its own keypair: a private key and a public key signed by the issuer. The issuer can be a CA or the Habitat itself. Furthermore, each Habitat has a keystore containing trusted certificates storetrusted, and a keystore containing revoked certificates storerevoked.
Certificate issuers can form chains: A certificate higher up the certificate chain is called a parent certificate.
CA1 issues a certificate for CA2, which in turn issues a certificate for CA3, which in turn issues a certificate for entity X. In this example, the parent certificates of X are CA1, CA2 and CA3. The parent certificate of CA2 is CA1. CA1 has no parent certificate[11].
When a connection is initiated, both Habitats check the other side's certificate, based on the information in their keystore. The procedure is as follows:
The certificate C of the other party is obtained as according to the TLS specification; this includes chain verification.
If C or one of its parents is expired, the connection is refused.
If C or one of its parents is contained in the storerevoked, the connection is refused.
If C or one of its parents is contained in the storetrusted, the connection is accepted.
Otherwise, the connection is refused.
Each attempted connection, whether it was accepted or refused, will be logged.
Note
Trust is neither symmetric nor transitive. It is even possible to have a setup where trust is not reflexive, although this is not advised.
In other words: if Habitat A trusts Habitat B, this does not imply that Habitat B trusts Habitat A (symmetry).
If Habitat A trusts Habitat B, and Habitat B trusts Habitat C, this does not imply that Habitat A trusts Habitat C (transitivity).
It is also not implied that Habitat A trusts itself (reflexivity).
While Secure JXTA provides a variety of possible trust models, the ADK has chosen for this model for the following reasons:
It is conceptually compatible with ADK versions before 2.0.
The implementation of trust (distributing certificates) is centralized.
The verification of trust is decentralized. This removes potential bottlenecks in large networks.
The trust model is decidable; at any given point, it can easily be shown whether a connection will be set up or not.
Note
The ADK provides no explicit support for Certificate Revocation Lists. However, by storing revoked certificates in a separate keystore, identical behaviour can be obtained.
In order to improve the understanding of security concepts, the Habitat requires three keystores for secure communication:
One keystore containing only the private key of the Habitat, and its accompanying certificate.
Storing this in a separate keystore makes it very easy to distribute Habitat keypairs apart from the Habitats themselves. The receiver only needs to copy a keystore to a specified location.
One keystore containing the certificates of all trusted CAs.
One keystore containing all the revoked certificates. Expired certificates need not be in this keystore.
This can be graphically explained as follows:
The previous keystores were all for secure communication; however, agents are also related to certificates. This is explained in the following picture:
Here, we can see the following files:
A keystore containing the developer's keypair. This is used for agent signing at deployment time.
A keystore containing the (parent)certificates of all trusted agents.
A mapping from certificate to set of permissions, called the Roles.
At the danger of repeating ourselves, it should be stressed again that these keystores and role definitions are not about secure communication.
Combining these pictures, we come to the following, typical Habitat setup.
Habitats often serve as relays[12]; whichO are used to communicate over firewalls.
The security of relays has no impact on the security of communication between two habitats, even if this communication is routed through an unsecure relay.
The TLS protocols runs on top of the basic JXTA peer to peer information. This implies that TLS packets never need to be decrypted and reencrypted on relays.
While TLS introduces non-repudiation; this occurs only on the level of Habitats sending messages to other Habitats[13]. Non-repudiation is not available on the agent level.
Furthermore, information used in the TLS (signatures, certificates of other Habitats, chains) is not passed to the Agent level.
Since a Habitat is both identified by its habitat ID and its certificate, it follows that the certificate of a habitat is a good place to store the Habitat ID. Habitat IDs are stored in certificates as a X509 extension.
The X.509v3 certificate allows the definition of so-called V3-extensions. In order to embed IDs (see ???), we have defined the HabitatID extension.
Figure 6.1. ASN.1 notation of V3 extensions
Extension ::= SEQUENCE {
extnID EXTENSION.&id
critical BOOLEAN DEFAULT FALSE
extnValue OCTET STRING
}
When comparing the Habitat ID extension to the ASN.1 definition in Figure 6.1, “ASN.1 notation of V3 extensions”, the extension ID has been defined as "1.3.6.1.4.1.9727.1". The extension value is the byte-representation of the ID. The extension is not critical, allowing other applications to ignore this field.
To use secure communication, a Habitat key pair must be available and must contain a Habitat ID.
Note
There are other ways to identify habitats: by host and port name, or by IP number and port name. These schemes are not guaranteed to be unqiue, and work only in a closed network environment. Since hostname, IP addresses and port numbers are not embedded in the Habitat certificate, the security of these addressing schemes is weaker than identifying a Habitat by its Habitat ID.
To enable secure communication with other Habitats, the Habitat key pair must be set up. If no Habitat key pair is available, the habitat will not be able to initiate secure communication.
A habitat can advertise two types of communication pipes.
Insecure. These pipes do not provide any security but are reliable.
Insecure communication is used for communication with peers that are not capable of doing secure communication. For example, the Tiny implementation of the ADK does not allow for TLS communication. In most cases, the connection between the small device and the proxy is physically secure, so no extra measures are neccesary. No habitat key pair needs to be available to advertise the unsecure pipe.
Secure. These pipes provide over the wire encryption and reliability.
Secure pipes come in two flavors: with or without a trust model. In the former, incoming connections are accepted if they comply with the trust model. In the latter, incoming connections from any peer that has a certificate are accepted.
Communication without trust model is a mode where transmitted data is encrypted and guarded by TLS against tampering, but no check on the identity of the communicating party is done. This mode can be used by Habitats that need to communicate with other Habitats that are unknown, not even by their CA. The security domain consists of all habitats in the universe. Since a secure communcation endpoint is advertised, the Habitat key pair must be available. XXX: is this para still valid? BR.
For a list of all properties, refer to Section 7.2, “Properties”.
[8] Transport Layer Security, also known as SSL version 3.
[9] Technically, eavesdropping itself is not prevented. However, eavesdropping will not reveal any information, since the information is encrypted.
[10] Signing XML documents is not trivial.
[11] Technically speaking, self-signed certificates have themselves as the parent certificate.
[12] Habitats can become relays by setting the property messenger.role to habitat.
[13] Non-repudiation means the following: if Habitat A sends a message to Habitat B, and this information is logged by Habitat B, Habitat A can no longer (plausibly) deny that this message was ever sent.