IberAgents Security

This page explains how the current implementation of security features works, how to use them, and what you should not expect from them. The page is just a first version; it should be expanded with more details in future revisions.

You can browse the online documentation for supported features, a user guide and an architecture guide. The status of the framework can be useful to decide whether IberAgents is suitable for use in a given project.

Introduction

Security plays an important role in any web application: whenever you move from a set of static pages freely available to dynamic content, you have to think about who does what and, more importantly, who should not do it. The restrictions that have to be imposed on the system to limit it must be enforced and verified, preferably by external experts.

Our main goal in the design of IberAgents security was simplicity; a simple design can be verified with more confidence than a complex one. The next priority was to follow a recognized and widely used set of standards; reinventing the wheel is also a bad security practice. Last but not least, we tried to follow the same design found in the rest of the framework, so that components integrate nicely.

We will start with a brief section on PKI essentials, and a practical tutorial on digital certificate generation. Secure services are discussed next, followed by password management, an overview on how passwords are dealt with in the platform. In modes of operation you will see how to use, enable or disable different security options. The disclaimer is intended to put in scope IberAgents security. Finally, the conclusion wraps up with a summary of recommendations.

PKI

Public cryptography has done much to enable secure communications over the public internet; but before this goal could be achieved, an infrastructure had to be set in place that goes beyond simple Alice-and-Bob constructs. The basic arrangement by which multiple parties can agree on a common set of secrets and prevent others from learning them is called a Public Key Infrastructure or PKI.

The main goal is to allow two parties (traditionally called Alice and Bob) who have never met each other to share public keys in a trusted manner. The solution proposed by a PKI is to have a trusted third party (the Certificate Authority or CA), to which both participants go to verify their mutual identities. This is done through digital certificates; essentially, the CA receives a request from Alice to extend a certificate; it verifies her identity, and then digitally signs it. The resulting signed document is called a digital certificate.

Now, when Bob wants to check Alice's public key, he is presented with this certificate; since he also has access to the CA's public key, he can verify that the signature really belongs to the CA and therefore that the CA has certified the public key. He can now use it to establish a secure channel using the Secure Socket Layer protocol, or SSL for short. If Alice wishes to verify Bob's key, she will do the same with Bob's certificate.

Therefore, we need several elements before we can communicate securely: a CA, its public signature, and digital certificates for each party that initiates a communication. The next section discusses how to obtain them.

Digital Certificates

The first step is to identify a CA. Commercial CA's abound, but they charge money for their services; we will create our own for the purposes of this tutorial. The OpenSSL project provides tools to build your own CA with simple commands.

The next step is to get a digital certificate. Using the tool provided with J2SE, keytool, we generate our private and public key pair into the file keyStore, and then generate a request for a signed certificate. This is passed along to the CA, which (again using OpenSSL) signs it and produces the desired certificate. It is also stored into the file keyStore.

Our final step is to get the public key of the CA. OpenSSL can be used to generate it inside a root certificate, which is a certificate that contains a public key and is signed using the corresponding private key. Again using keytool, this certificate is imported into the file trustStore, which contains the root certificates for all trusted CA's.

The standard distribution comes with default certificates generated as part of the development process. You have to enable certificate loading manually.

Be sure to replace the default certificates with those obtained by you, since they contain the private keys and offer therefore no security at all.

Secure Services

Version 1.3 introduces the class SecureNode; apart from the host, port and directory included in a regular Node, it also contains a secure port to use for SSL connections.

Whenever you want to make sure that a service is only accessed remotely using a secure channel (i.e. via SSL), you should make it inherit from SecureService. This way, a web service that belongs to it will only be invoked if the remote node is also a secure node, and in this case it will use SSL.

Password Management

Authentication to components is performed using user id and password combinations. The password should not travel or be stored as cleartext (unencrypted form) if at all possible.

Challenge-Response

When a user logs in to her component, she is presented with a login page. Since version 1.3 the password is not sent as cleartext; a challenge-response mechanism is used to ensure it stays confidential, and also to avoid replay attacks (eavesdropping on login data and using it at a later occassion).

The server sends a random value called the challenge; the browser receives it hidden inside the HTML code. When the user enters the password, a hash of the password combined with the challenge is computed and sent back to the server as the response. Upon receipt of this data, the server performs the same computations using the stored password and then checks that both values are the same.

If a malicious attacker gets the hash, she will not be able to use it later, since the challenge will be different each time.

Password Serialization

Also since version 1.3, passwords are not stored to file as cleartext. Instead, its MD5 hash is computed and this value is serialized to disk.

Although this measure helps keeping the password secret, it does not help to prevent unauthorized logins: they can be computed using the MD5 hash and the challenge.

Protect those files that contain password values: platform.xml and the whole directory database.

Modes of operation

Depending on the conditions, IberAgents can operate with security disabled. You should verify that it is not allowed when manipulating sensitive information and performing delicate operations.

Insecure Web Services

When a service inherits from SecureService, it explicitly requires use of a secure channel for web service communications. However, a regular Service can communicate both over a secure channel and using insecure connections. Be sure to use a secure service for sensitive operations.

Insecure Web Administration

IberAgents users can perform several administrative tasks using a web interface, such as editing the configuration or monitoring agents. The relevant components can be accessed using the secure protocol SSL, but also with the insecure HTTP protocol. This can be a problem in certain circumstances: e.g., when the administration password is modified, it will be sent as cleartext (see below).

Cleartext Passwords

When javascript is not enabled in the browser, operation defaults to sending the passwords as cleartext (i.e. not encrypted). This is quite dangerous, since it can lead to compromise of user data and even of the whole system. It can be disabled by modifying the script in hash.js.

When editing a user's password, the current value is not sent to the browser. However, when the user changes the password, the new value is sent to the platform as cleartext. If you don't want to expose system security you should disable this option for sensitive components; IberAgents does not currently offer any facility for this, but you might filter the insecure port out.

Enabling Certificates

A parameter enabled has been added to the certificate manager, in CertificateConfiguration. You can enable certificate loading or disabe it altogether, in which case IberAgents will not open the secure port even if the node is secure.

To enable certificate loading, open up the configuration editor, select the container for platform.xml and then the configuration for CertificateManager. Set the parameter enabled to true, and store the new preferences. Then restart the platform.

On some machines, after loading the certificates the machine consumes 100% CPU during a few minutes. Also, memory consumption is quite high: several hundred MB. We are investigating the issue; it seems to be related to the JVM version.

Secure and Insecure Challenger

There are two variants of the Challenger component, responsible for generating challenges and computing MD5 hashes. The SecureChallenger uses a cryptographically secure PRNG (Pseudo-Random Number Generator): based on Sun's JCE, it should generate secure pseudo-random numbers. In contrast, the InsecureChallenger uses the regular java.util.Random class, seeded with the startup time; this means that random numbers (and therefore challenges) are fairly guessable, but startup time might be noticeably smaller.

It should not matter too much if the next challenge is guessed; but an insecure PRNG can repeat numbers far too often. When a challenge is repeated, the response is identical and an attacker can replay the old value.

Do not use the InsecureChallenger if you are allowing remote login to important components, since it opens the door to replay attacks. The SecureChallenger should be significantly more secure.

Disclaimer

As you may have heard several times from different experts, "security is a process, not a product". This is the first iteration of most security features; even though we spent our best efforts into making the framework as secure as possible, it will likely have some flaws which might leak confidential data.

Even security-conscious and mature projects like Apache or MySQL regularly find flaws in their code; sometimes it takes various iterations before a feature is implemented right.

Please do not use IberAgents if you intend to deal with sensitive data, or disruption of operation would cause you harm. If you choose to do so, do it at your own risk. We offer no guarantee at all.

Conclusion

This is a first implementation of several security features that makes use of public-key cryptography, digital certificates and secure hashes.

Do not use IberAgents for sensitive applications before making a rigorous analysis of your needs and requirements, and verifying that the current implementation meets them. In particular, please make sure that you use real certificates in place of the demo certificates distributed with IberAgents; and that you do not edit passwords over an insecure connection.

We invite independent researchers to study the operation of IberAgents and verify the design and implementation of security features. Please submit any issues you may find to the mailing list; we will deal with them as fast as possible.