Subscribe to News

From TechnologicalWiki

Contents 1 Threats in bundles development 2 Platform components 2.1 Bundles 2.2 OSAmI repository 2.3 OpenID server 2.4 Applet signature 3 Platform processes 3.1 Process of signing a bundle 3.2 Process of Verifying the signed bundle

Threats in bundles development

The secure distribution of software components is currently a critical factor for all users and not just for programming companies. It is becoming more frequent to see software attacks based on the use of malware or substition of programs (or software components) in the repositories to which end users (or machines) have access. This situation is somewhat accuentuated by the intrinsic dynamics of programming and the execution of those software components, in which several programmers can play a part deploying a particular service (or parts of).

Given the increase in the features of mobile devices, an application exists for practically any need, and it’s here integrity of software or trust in the programmer are fundamental goals to pursue. The proliferation of available applications for every type of device and for mobile devices in particular has, in addition, meant that an increasing number of programmers distribute these applications. Not all of them can be given the same level of trust if we don’t want for malware to have an open door to our systems.

This situation worsens in an environment in which the services (programs running) are made up of dynamic modules or components in real time, as is the case of the OSGi platform. The OSGi platform is a system of modules and services for the Java programming language that uses a complete model and dynamic components. The applications or components (in bundle form) can be installed remotely, started up, stopped, updated and uninstalled without restarting. The life cycle is managed through APIs which allow the remote download of management policies. The Service Registry allows bundles to detect the addition or suppresion of services and adapt themselves as a result. The OSGi specifications have moved on from the original approach and are now used in applications from mobile phones to IDE from Eclipse passing through a wide spectrum of application areas as hetrogenous as can be: cars, industry automation, building automation, mobiles such as PDA’s, entertainment and leisure, fleet management or application servers.

So, the scenario we are presented with (see Figure 1 for more details) is of a device which supports OSGi with the aim of achieving the dynamic execution of components featuring a constant connection to different OSGi repositories of those that will load the distinct bundles according to the dependencies and necessities of those bundles already running. Our solution has to take into account the point of view and necessities of this device and of the programmers to provide integrity and trust at the moment of running these components on a par with the ease of use and simplicity at the moment of uploading these components to the repositories.

The security threats to the deployment of the bundles can be of three types:

• The presence of malicious repositorios for publishing the bundles
• “Man in the Middle” attacks where an attacker modifies a bundle or substitutes it completely with another when uploading or downloading.
• It is possible that an attacker accesses the bundle repository or the client platform in order to modify the components stored there.

After analysing the scenario and its principal threats, we draw the conclusion that the main requirements are as follows:

• Simplicity
• Mobility/Portability
• Authentication of programmer
• Integrity of the bundles
• Generating secure signatures

Figure 1. Threats in bundles development process

[edit] Platform components

[edit] Bundles

A bundle is no more than a JAR (Java Archive) file that also contains a metadata set which specifies the component’s characteristic. These metadata are included inside the file MANIFEST.MF. So:

Bundle = file JAR +MANIFEST.MF. with metadata

It is necessary to give some sort of support for the life cycle of the bundles, from installation to execution and deletion, so the security has to be taken into account throughout the life cycle.

[edit] OSAmI repository

Read about OSAmI repository here.

[edit] OpenID server

OpenID is a decentralised digital authentication system, with which the user can identify themselves in a webpage through an URL (or XRI in the latest version) and can be verified by any server that supports that protocol. In those sites that supoort OpenID, users do not have to create a new user account to access the site. Instead they only need to already have an identifier created in an OpenID server (OpenID provider) i.e an OpenID identity provider (IdP).

This identity provider can confirm the OpenID identification of each user in any site that supports this system. Unlike SSO (Single Sign-On) architectures, OpenID doesn’t specify the authentication mechanism. So, the security of an OpenID connection depends on how far the OpenID client trusts the identity provider. If they do not trust the provider, the authentication will not be suitable for bank services or shopping online. However the identity provider can use strong authentication, if the Service Provider requires it to.

Among the attributes of OpenID, the following have been chosen to generate temporary certificates:

• openid.ext1.value.firstname (en adelante, firstname)
• openid.ext1.value.lastname (en adelante, lastname)
• openid.ext1.value.email (en adelante, email)
• openid.op_endpoint (en adelante, ID provider)

By choosing OpenID we hope to avoid the centralisation that a hierarchical system like PKI implies which drains dynamism from the platform and introduces a dependency on the availabilty of the CA hierarchy to generate the certificates. In other words, what we gain through this is to avoid the necessity of personally going to a Registry Authority.

[edit] Applet signature

The programmer requires the signing and creation of the digital signature certificates of the signature, download and execution an applet is required. The signature applet only takes as user input the destination repository, as well as the bundle that the user wants to be signed.

As auxiliary support for signing bundles two tools from Java have been used: Jarsigner and Keytool.

• The Jarsigner tool has two main aims: Signing JAR files and verifying said signature and the integrity of signed JAR files. It uses the information from certificates and keys that it gets from a keystore to do this. A keystore contains a database with private keys and certificate chains X.509 that authenticate its public keys.
• The Keytool tool is responsible for managing the keys and certificates in a way that allows users to administer their own public and private keys and the certificates associated with them to authenticate themselves for other users or services or to carry out integrity verifications by using digital signatures.

A user can come across two different types of input that make up part of the storage for keys

• Keys: A stored key is usually a private one together with the corresponding certificate chain of its public key.
• Trusted certificate: Trusted certificates are those public key certificates of another user or entity the identity of which is known for certain

There are other Keytool options for importing to the keystore existing certificates, to export certificates, to generate self-signed certificates or to generate CSR requests that are later signed by a CA, which is the option we have implemented.

[edit] Platform processes

The final goal of this platform is the secure distribution via a repository, of software components. To enable this we use the I.D information provided by an OpenID server in order to create temporary certificates that are finally signed by an online CA service provided by the repository itself and are then used to sign the bundle, as the step prior to loading it into the repository.

[edit] Process of signing a bundle

The solution put forward to provide security in the bundles is a digital signature that, because of the peculiar characteristics of the bundles, has to be stored within the bundle together with the rest of the components. The relative files together with the signature of the bundle are as follows:

• Manifest File contains a list with a hash value of each of the resources of the bundle.
• To hold multiple signatures, the digital signature is not applied directly over the manifest files but rather over a file for the signature called Signature File,that contains a hash value of the manifest file. There is one signature file for each signatory.
• The digital signature of the signature file is stored in a CMS (Content Management System) file called a Block Signature File. The extension of this file is the name of the signature algorithm (.dsa, .rsa, among others) Furthermore this file contains the necessary data to verify the signature, such as the certificate chain that verify the users signing that in our case would be the chain formed by the temporary certificate created by the attributes of the OpenID of the user and the certificate of the public CA online key in the OSGi repository.

Figure 2. Signed bundle structure

In our implementation the order of these resources inside the bundle is as has just been described. All these files are placed infront of the rest of the resources of the bundle. This order should be one of the aspects to be taken into account during the signed bundle verification process. Figure 3 demonstrates the interraction between the components of the platform. The flow of information in the process of signing a bundle is shown step by step below:

Figure 3. Bundle signing architecture

• The programmer connects to the service that uploads the bundles to the repository (Bundle Upload)
• The first step is to access the URL of the applet download. On accessing the URL, it checks if the user entered with OpenID attributes and if they haven’t they are redirected to a WAYF (Where Are You From) service.
• The WAYF service allows the user to select their OpenId provider, and redirects them to the provider.
• The user introduces their username and password to authenticate themselves in the OpenID server which allows the server to send the user’s OpenID attributes to the redirection page which is the URL of the applet download.
• With the second access to the URL of the applet download, the OpenID attributes are checked and if correct the download process is started. In the user’s browser their permission is asked for in order to execute the applet from the trust in the certificate of the programmer of the applet.
• From the OpenID attributes with which the applet is initialised, a pair of codes, public and private, are generated with the correpsonding CSR (Certificate Signing Request) request. The necessary fields for the keys are filled in like so:
  • Common Name: firstname + lastname
  • Organisation Unit: email
  • Organisation: ID provider
  • Country: ES
• The CSR is sent to the repository online CA service.
• The CA online service generates a key certificate from the CSR and the private key of the CA.
• The online CA sends the public key certificate, together with the CA public key if necessary. In the applet the public key certificate and the private certificate are joined, and the user now has the capacity to sign software components with the complete temporary certificate.
• The signing process of the bundle is carried out from the temporary certificate obtained and the bundle is sent to the repository.

The main reason for choosing an applet as the central element of the platform in the signing process is that the two keys, public and private should be generated locally on the user’s equipment (so that the programmer can really trust the keys generated) but from existing software in the platform.

Figure 4. Applet for signing bundles

So, the user can dowload the applet in the browser and authorise its execution (trusting the author) during the automatic download of it. The security of the applet and how the user shows their trust in it by authorising its execution has already been solved.

Figure 5. Java classes involved in the signing bundles process

[edit] Process of Verifying the signed bundle

The verification process is carried out in exactly the same way as the signing process with the following steps:

• The first step is to validate the identity of the signatory so the chain of trust of the certificate has to be verified, checking that it is only made up from the certificate of the public key of the repository online CA; also checking that said CA is to be found in the store of the trusted certificates (truststore). Furthermore the attributes of the temporary certificates should be shown, so the client can decide whether to trust the OpenID provider which has provided the attributes with which the temporary certificate was generated.
• The second step in the verification process consists of checking if the resources inside the bundle are in the order that was described in the specifications: manifest file, hash file (Signature File),signature file (Block Signature File) and then the rest of the bundle files.
• The third and last step is to verify the matching of the metadata files: the signature file should contain a valid signature from the hash file, the hash file should contain a hash value valid for the manifest file and the manifest file should contain the name and hash value of each and every one of the bundle’s resources.

Figure 6. Verification process of a signed bundle

In our implementation we have decided that the verification of the signature is done in the repository itself, in such a way that it incorporates the result of said verification in the view it displays to the user so that they can decide which bundles to trust without overloading the device which will execute the bundles. Obviously this implies that there has to exist a relationship of trust with the repository servlet which is responsible for verifying the signature, even though in our scheme we assume the repository is always trustworthy. In any case the user can download the signature togther with the bundle and verify them locally for a greater level of secuirty.

So we are able to describe the authentication process of the bundles from the following point of view:

• The client connects to the service that shows the list of the bundles available in the repository.
• For each bundle, the repository should show:
  • The bundle’s own attributes, like name, size or creation date
  • The OpenID of the programmer/signatory of the bundle
  • The OpenID identity provider( so the client can decide whether they trust it or not)
  • The CA that certifies said identities
  • Some sort of error message in case any errors are produced during the verification process

Upon seeing this information, it is left up to the client to decide finally whether to download the bundle and whether or not to execute it.

Source: "Distribución segura de componentes software basada en OpenID". Isaac Agudo, José Antonio Onieva y Daniel Mérida. RECSI 2010"