O.C.E.A.N. Project
Security Component Specification
This document is to be maintained as the official reference specification for the Security
component of the OCEAN system.
Component’s Role in OCEAN System Architecture
The Security component is present in each OCEAN node. It is primarily used by
the other components of the OCEAN architecture like Negotiation, Auction, TSM,
Accounting, PLUM, Communication and Node Configuration Layer.
Main functionality of the security layer is to provide services like authentication, nonrepudiation, integrity and confidentiality.
Financial Network
Centralized
Accounting Server
Node A
Node B
Security Layer
Security Layer
Certification Authority
Security Component Specification
Page 1
Services provided by the Security layer:
Security layer provides the security services at following instances:
1. At the time of node creation.
2. Communication between the OCEAN nodes
3. Communication between an OCEAN node and the Centralized Accounting Server
(CAS).
4. Communication between an OCEAN node and the Certification Authority (CA).
5. Communication between the CAS and CA.
1. At time of node creation
a.
b.
c.
d.
e.
Distribution of Keys during installation of the software.
Registration with CA.
Registration with CAS.
Generation of key pairs.
Secure storage of keys, both at local node and CA.
2. Communication between the OCEAN nodes:
a. Generation of session keys for cryptographic requirements.
b. Key distribution for peer-to-peer communication.
c. Secure storage of keys to prevent loss and to provide immunity against
attacks.
d. Communication with CA for verification.
e. Decryption of information that is exchanged between the different layers of
the peer nodes.
f. Acquisition of certificates from CA.
g. Support for challenge-response authentication.
3. Communication between the OCEAN node and Centralized Accounting Server:
a. An OCEAN Node registers itself with the CAS at the time of its creation.
b. The local node communicates with the CAS to add the contract information
after the negotiations are done.
c. The local node updates the account information regarding the transaction,
after the completion of the job.
d. When the node is reinitialized, after a crash/failure, it asks the CAS for its
transaction history, contract information and keys.
e. The CAS resolves all disputes regarding the transactions between the nodes
(non repudiation).
Security Component Specification
Page 2
4. Communication between the OCEAN node and Certification Authority:
a. When a node is created for the first time:
 Registration with CA.
 Generation of key pairs.
 Secure storage of key pairs in the CA and the local node.
b.
c.
d.
e.
Authentication services.
Generation and distribution of certificates.
Revocation of expired certificates.
Support for challenge-response authentication.
Note: Communication between the OCEAN nodes and the CA is secured.
5. Communication between the Centralized Accounting Server and Certification
Authority:
a. Authentication of the signatures of the nodes involved in transaction, after the
contract is finalized.
b. Support for SSL/TLS communication (assuming CA and CAS are secured).
c. Support for challenge-response authentication to prevent replay attacks.
Node Configuration/Operation Layer
Negotiation Layer
Auction Layer
Task Spawning and
Migration
Accounting
Layer
(Local)
Plum
Security Layer
Naming
Communication Layer
Centralized
Accounting Server
Security Component Specification
Certification Authority
Page 3
Handling Exceptional conditions
During communication between nodes or between nodes and server,
exceptional conditions may arise. It is necessary to handle these conditions and
propagate information to the appropriate layer/node. Few exceptional conditions
that may arise are as follows:
1. If there is loss of communication between two peer nodes or between a
node and a server then the communication layer sends an exception
condition to the security layer.
2. If signatures do not match during verification then following actions are
taken:
a. The CA sends exception conditions to the appropriate nodes and to
the CAS.
b. At those nodes, security layer propagates the exception message to
the upper layer or takes appropriate actions.
c. The node, whose signatures didn’t match, loses trust in the network.
Note: More exceptional conditions have to be handled.
Functional Needs:
1. Needs for the Node Configuration Layer:
a. Using the GUI, node operator can change the security level for the
communication between the nodes or with the server.
b. There are three security levels, which can be selected by the local operator.
They are:
i. Low
ii. Medium (Default)
iii. High
2. Needs for the Auction, Negotiation and Accounting Layer:
The needs of the auction, negotiation and accounting layers are similar in terms of
security, as they exchange information in the form of the XML documents. These
documents have to be securely transmitted between the nodes or between the
nodes and the server (in the case of the accounting layer).
3. Needs for the PLUM Layer:
a. For testing the roundtrip communication characteristics (bandwidth,
latency…etc.), it requires basic communication services rather than secured
communication.
b. Secured communication is required when PLUM layers exchange information
regarding node resources.
Security Component Specification
Page 4
4. Needs for the Task Spawning and Migration Layer:
When TSM sends job/task to the remote machine, it sends the task/job (as an
object or a jar file) and permissions associated with that code in the form of a file.
5. Needs for the Centralized Accounting Server:
a. CAS requires that each node should register/update itself with it and should
provide information like credit card, account information etc.
b. CAS needs to quickly receive information in a secure manner, about the local
transactions (contracts) from the OCEAN nodes.
c. CAS needs to update the accounting information after the job completion.
d. In the case of failure, CAS requires to send all the information (account
information/ contracts) back to the reinitialized node.
e. CAS needs to perform authentication of nodes by communicating digital
signatures to the CA.
6. Needs for the Communication Layer:
a. Communication layer requires data and OCEAN name of the destination node
for initializing communication channel between peer nodes.
b. Communication layer needs to communicate to the Naming layer to extract
the address and port of the destination node.
c. Communication layer may need to implement secured communication using
SSL*.
Requirements
Below are the requirements for the Security Layer.
1. Requirements for the Node Configuration Layer:
The security layer should provide interface to the Node Configuration Layer to
allow it to alter the security levels. By default medium level of security is
provided.
Note: The details of security levels are not provided to the operator. The security
layer takes care of the encryption and decryption according to the selected
security level.
2. Requirements for the Auction, Accounting and Negotiation Layers:
a. When the auction, accounting or negotiation layer on an OCEAN node needs
to exchange XML documents with the corresponding layer on the destination
nodes, it provides the OCEAN Name and XML documents to the security
layer.
b. The security layer quickly retrieves the public/private keys or session keys
(depending on the security level which has been set and the context of
communication).
Security Component Specification
Page 5
c. The security layer selects the algorithm required to perform
encryption/decryption.
d. The security layer then encrypts the information and sends the encrypted data
to the communication layer.
e. On the receiving end, it receives the encrypted data, decrypts the information
and performs verification if necessary.
f. Using the services of the OCEAN Naming System, it determines the higher
layer to which it has to pass on the information.
g. Thereafter the security layer passes the data to the upper layer.
3. Requirements for the PLUM Layer:
a. No security is required when messages are exchanged between the peer
PLUM layers, to determine the round-trip communication characteristics.
b. However, secured communication or encryption/decryption is required when
PLUM exchanges information about the node resources (cpu cycles, memory,
disk etc.).
4. Requirements for the Task Spawning and Migration Layer:
a. Security layer offers various services to the TSM layer, to migrate a job/task
to its peer layer on another OCEAN Node.
b. On the sender side, security layer encrypts the OCEANTask object and the
permission file together and sends the encrypted object along with the address
of the destination node to the communication layer.
c. On the receiver side, the security layer decrypts the combined object and
sends the OCEAN task and the permission file to the TSM layer.
5. Requirements for the Communication Layer:
a. Security layer sends the encrypted/raw data and address of the destination
node to the communication layer.
b. Security layer notifies the communication layer, whether to use simple sockets
or secure sockets (using SSL) for the communication.
Security Component Specification
Page 6
Interface
The API requires and utilizes a set of standard names for various
algorithms, padding schemes, providers, etc. This specification establishes
the following names as standard names.
SHA-1 (also SHA): Secure Hash Algorithm, as defined in Secure Hash
Standard, NIST FIPS 180-1.
MD5: The Message Digest algorithm RSA-MD5, as defined by RSA DSI
in RFC 1321.
MD2: The Message Digest algorithm RSA-MD2, as defined by RSA DSI
in RFC 1423.
RawDSA: The asymmetric transformation described in NIST FIPS 186,
described as the "DSA Sign Operation" and the "DSA Verify Operation",
prior to creating a digest. The input to RawDSA is always 20 bytes long.
RSA: The Rivest, Shamir and Adleman AsymmetricCipher algorithm.
RSA Encryption as defined in the RSA Laboratory Technical Note
PKCS#1.
DSA: Digital Signature Algorithm, as defined in Digital Signature
Standard, NIST FIPS 186. This standard defines a digital signature
algorithm that uses the RawDSA asymmetric transformation along with
the SHA-1 message digest algorithm.
MD5/RSA: The Signature algorithm obtained by combining the RSA
AsymmetricCipher algorithm with the MD5 MessageDigest Algorithm.
MD2/RSA: The Signature algorithm obtained by combining the RSA
AsymmetricCipher algorithm with the MD2 MessageDigest Algorithm.
SHA-1/RSA: The Signature algorithm obtained by combining the RSA
AsymmetricCipher algorithm with the SHA-1 MessageDigest Algorithm.
DES: The Data Encryption Standard, as defined by NIST in FIPS 46-1 and
46-2.
IDEA: The International Data Encryption Algorithm (IDEA) from
ASCOM Systec, Switzerland.
RC2: SymmetricCipher algorithm proprietary to RSA DSI.
RC4: SymmetricCipher algorithm proprietary to RSA DSI.
Security Component Specification
Page 7
Package OCEAN.Security
--This package contains classes that are used for inter node secured communications.
The Security component stores default security parameters in a configuration file called
“Default Configuration File (DCF)”, which is an XML document. There is a copy of the
DCF, which is called “Customized Configuration File (CCF)”. User has an option for
either using default configuration or customize the security parameters using Node
Configuration/Operation API. When user customizes security parameters then CCF will
be altered and parameters will be read from CCF otherwise CCF would be overwritten by
DCF.
Class ConfigureSecurity
{
//This class contains the methods to access and manipulate the configuration files.
// Configuration file will be a XML document, which can be customized by the
user.
String encAlgorithm, certPath, keyPath, ccfPath, dcfPath;
int keyLength;
String readFile(String XMLdocPath, String searchCriteria);
void writeFile(String XMLdocPath); // this will only be created when user wants
to customize security parameters. It
creates a copy of the original XML
document (config. file) in which the new
parameters would be edited.
String getIPAddressOfCA();
void setIPAddressOfCA();
String getIPAddressOfCAS();
void setIPAddressOfCAS();
int getPortOfCA(); // assuming port addresses will be fixed.
int getPortOfCAS();
void getOS();
}
Security Component Specification
Page 8
// This class will be used by a node, CA and CAS to generate keys for authentication and
secured communication (excluding SSL).
Class KeysUtil
{
// This class generates public and private keys. This method also provides a
mechanism to store and retrieve the keys from the KeyStore.
private byte[] privateKey, publicKey, sessionKey;
private String keyAlgorithm;
private int keyLength;
protected void generatePublicPrivateKeyPair(String Algorithm, int keyLength);
protected void generateSessionKey(String Algorithm, int keyLength);
public void storePrivateKey(byte[] privateKey, String Location);
public void storePublicKey(byte[] publicKey, String Location);
public void storeSecretKey(SecretKey key, String Location);
public byte[] getPrivateKey();
public byte[] getPublicKey();
public byte[] getSessionKey();
}
// This class provides methods to generate certificates, store, retrieve and verify them.
Class OCEANCertificateUtil
{
protected void storeCertificate(Certificate cert, String location);
protected void sendCertificate(IPaddress addr, int portNumber);
protected void verifyCertificate(byte[] publicKey);
protected Certificate retrieveCertificate(String location);
protected PublicKey retrievePublicKey(Certificate cert); // retrieves public key
from the certificate.
protected void createCertificateChain(Certficates[] cert);
protected void verifyCertificationPath(Certficates[] cert); // verify chain of
certificates
}
Security Component Specification
Page 9
// This class extends OCEANCertificateUtil and is used by the CA. It provides method to
generate certificate and send it to the node or any other server.
Class OCEANCertificatesCA extends OCEANCertificateUtil
{
public Certificate generateCertificate(dataStructure Name, byte[] publicKey,
dataStructure issuer, byte[] privateKey, DataStructure time);
public void sendCertificate(IPaddress addr, Port, Certificate cert );
}
// This class extends OCEANCertificateUtil and is used by a node. It provides method to
request certificate from CA, retrieve public key from the certificate and verify the
certificates.
Class OCEANCertificateNode extends OCEANCertificateUtil
{
byte[] retrievePublickKey(Certificate cert);
void verifyCertificate(byte[] publicKey, Certificate cert); //Verifies that this
certificate was signed using the private key that
corresponds to the specified public key.
Certficate getCertificate(IPaddressCA add, CAPort prt);
}
// This class provides method to sign an object or a file using the private key. It also
provides method to verify the signature and also request certificate from the CA.
Class OCEANSignature
{
public byte[] createSignature(String algorithm, byte[] privateKey, byte[] data);
public SignedObject createSignature(Signature sign, byte[] privateKey, Object
data);
// returns the serialized object with its signature
public void verifySignature(PublicKey key, byte[] signature, byte[] data);
public byte[] getSignature();
}
// This method encrypts and decrypts objects, files or data from input/output stream. It
also sends the encrypted data to the remote machine.
Security Component Specification
Page 10
Class OCEANEncodeDecode
{
private final int ENCRYPT_MODE, DECRYPT_MODE;
SealedObject so;
byte[] cipherText;
public void EnAndDecObject(Serializable Object, String algorithmModePadding,
String keyGenerationAlgorithm, String mode);
public void EnAndDecFile(byte[] input, String algorithmModePadding, String
keyGenerationAlgorithm, String mode);
public void EnAndDecInputStream(String algorithmModePadding, String
keyGenerationAlgorithm, String mode);
public byte[] getCipherText();
public SealedObject getCipherObject();
public void sendEncryptedData(IPaddress addr, int portNumber);
}
Security Component Specification
Page 11