Security is an important concern for ACE. The analysis needs to differentiate between the individual needs of each sub-system and the overall flow inside the system. Furthermore, several scenarios need to be taken into account and addressed. In general, safety issues are not part of this analysis but will be addressed separately.

Threat scenarios and possible countermeasures are given subdivided by and investigated in regard to authentication, authorization, integrity, non repudiation, and confidentiality. We need answers to the following questions, what kind of different "attacks" from both external and internal interfaces can we identify (threats); how can we authenticate the different actors (human and machine) so we really know who we're talking to (authentication); who is allowed to do what in the system (authorization); who did what at which point of time (non repudiation); and how do we encrypt and ensure the integrity of the communication/software/configuration data (confidentiality).

Security on the target and relay server needs special attention because they are most likely provided by a third party, might be accessible from the outside, and not easily reachable for maintenance. It is for example possible that a target is at a remote location, accessible via the internet, and requires days to be accessed physically.

Threat Scenarios

This analysis focuses on the OSGi framework and management agent part of the system and its interaction with a (relay) server as well as between the client (for this analysis we assume the client is a separate node, for our web based UI it just happens to be part of the server) and a server. The most likely scenarios are forced breakdown of the system (denial of service attack), malicious data that might change system behavior, attempts to take over control, and espionage.

1. (D)DOS - In general, it is not possible to prevent denial of service attacks. Attackers normally can find a way to overload the system. Regarding the management agent it would be for example possible to provide the agent with a huge amount of data to install so that the target either is running out of disk space or out of other processing resources. The same is possible for any other entity in the system if an attacker finds a way to make it accept data.
2. Malicious Data - An attacker might use malicious data as part of a DOS attack but it could be also used to gain control over the system or change some aspects of its behavior to make it easier to take over control or cause other harm.
3. Hostile Takeover - Attackers might be interested in taking control over (parts of) the system in order to either do espionage, change the behavior of the system to do work for them, or plainly destroy/disable entities (e.g., to harm competitors).
4. Eavesdropping - An attacker might be able to listen in on the communication between a target and its (relay-) server or the client and the server. This might allow to learn about the configuration of a target and getting hold of the installed software.
5. Physical Access - Another type of attack would be to gain physical access e.g., disassemble a target or a relay server in an attempt to steal its data and/or impersonate it. Probably the only way to avoid that is hardware encryption, which for ACE is out of scope (but can be used to further harden the system).

Countermeasures

On the target there are two entities that are important namely, the (relay) server which is providing the target with instructions and data/code, and the management agent (i.e., the target itself). Regarding the communication between a client and the server the secure checkout and commit of object repository versions are important as well as the auditlog. The interaction between the server and a relay server is a two way data exchange where the relay server is comparable to a target in regard to the instructions and data/code it needs to get from the server and to a server that sends the auditlog to a client. One plus point from the security side is that the target is only polling the server – hence, it is not accepting any connection requests from the outside. This reduces the risk of a DOS attack but by no means makes it invulnerable against it (especially since there is a high likelihood that the underlying platform is vulnerable to DOS attacks as well). One way of working around the polling restrictions are ARP and DNS injection attacks that might make the target contact the wrong server. This allows for malicious data, DOS attacks, and hostile takeovers.

A good start to limit attack possibilities is to decouple the sub-net of the target from the internet / external world by using relay servers but this doesn't prevent the mentioned attacks and threats in all cases. Furthermore, relay servers need to support both polling and being polled due to their different roles (they are polled by the targets, need to poll deployment packages or object repositories from the server, and push the auditlogs of targets to the server). Finally, the server is only polled.

Authentication

As mentioned above, the most likely way of attacking a target or relay server is to spoof its connection to the server (whether it is a relay server or the real one). It is dangerous to rely on DNS and/or IP addresses because both might be wrong. Given the issues at stake, authentication will need to be based on certificates. An entity of the system should have a certificate (that has the id as part of it's common name) as its identity.

Furthermore, it needs to have a keystore of trusted root certificates (CA) and a certificate revocation list (CRL). The (relay) server needs to have a certificate as its identity that is part of a chain of trust to one of the trusted root certificates of the target or client and vice versa. Basically, this can be achieved via two ways, one is to use https with server and client certificates; the other to use certificates to sign all messages/data using our own protocol.

Authorization

We have to differentiate between several areas where authorization is needed. The provisioning part needs to make sure it is installing deployment packages from an authorized server.

The target itself is running an OSGi framework and can subsequently, make use of the built-in security. This is needed if deployed software components can not be trusted and would be advisable to foster "least privilege" security in general. However, the management agent will need to be able to cooperate with the framework infrastructure to set-up needed rights. Special care needs to be taken to avoid installing malicious software in a framework with security disabled or with too powerful a set of rights. Due to the life-cycle capabilities of OSGi, a malicious or faulty bundle could for example uninstall the management agent itself if the bundle is started in the absence of security or with admin permission (This aspect is not part of this analysis and will be discussed as a separate user story).

Assuming the additional requirements in regard to integrity and authentication are satisfied it should be sufficient to ensure the server is authorized to make changes to the target – hence, in a certificate based approach separate chains of trust can be used to determine whether a server is trusted and is authoritative for a given target. In other words, the certificate of the server can be treated as a capability (revocation is then possible via a certificate revocation list). The same applies for clients and relay servers, respectively.

Integrity

Due to the fact that authorization to provision a given version (i.e., a set of bundles) is mainly based on whether or not the current authenticated server is authoritative for a target it is of great importance that the actual deployment package has not been tampered with.

The deployment admin specification already defines a way to ensure integrity building upon the fact that deployment packages are Java JAR files (which can be signed). Therefore, it makes sense to only allow deployment packages that are signed by a certificate that the target has in a chain of trust.

Furthermore, taking into account relay servers the trusted certificates can be limited further to for example only allow the actual server certificate.

Deployment packages can be signed by any number of certificates so it is possible to sign a deployment package multiple times in order to make it available to different targets that follow non uniform certificate trust strategies. The same is possible for the object repositories and the auditlog.

Non Repudiation

Several entities can be responsible for changes in the system. The individual entities need to make sure they record in a non repudiation fashion who was doing what for any action taken. Conversely, the server and possibly the relay servers need a way to ensure that for example auditlog entries are really from the target they are claimed to be.

One way to tackle this is to use certificates to sign all data and to make sure that for all data accepted from a different entity, the signature (including the fingerprint of the signing certificate) is recorded. Taking the auditlog as an example, a target would use its certificate to sign all entries in the auditlog. Subsequently, a server or a client can be certain that a given auditlog is originating from the target it is claimed to come from (assuming the private key of the target certificate has not been exploited).

Furthermore, it will be easy to invalidate data from compromised entities by adding their certificates to the certificate revocation list.

Another, more involved example, can be a target that receives a deployment package and installs it. In this case, the manifest containing all the signatures of the content of the signed deployment package as well as all the fingerprints of the certificates that signed it need to be added to the targets auditlog and this entry would be signed by the target certificate. After the log is synchronized back to the server (possibly via several relay servers or even manually) the server can determine who signed the deployment package and where it has been installed. The same applies for clients.

Confidentiality

In most cases the software that needs to be provisioned as well as the configuration of the targets needs to be kept confidential since it may contain business secrets. This can only be ensured by means of encryption because we have to take scenarios into account where communication happens via a none secure channel like the internet.

One secure set-up would be to use asynchronous encryption which would furthermore not rely on a point-to-point protocol but rather enable all the way confidentiality. Alas, the deployment packages might be big and asynchronous encryption would be to slow in this case.

The alternative is to use SSL (most likely by means of HTTPS). The downside of SSL as for example in HTTPS is that it is often hard to set-up and relatively inconvenient and static to use if the possibility of a man in the middle attack needs to be ruled out.

Possibly the biggest problem, in our scenario, is that we can not assume that the common name of an entity reflects its IP/DNS name. Relay servers might be operating in networks not under the customers or our control and the same applies to targets and clients (which could have dynamic IP's and hostnames for example). This problem can be overcome by ignoring the common name in regard to authentication which might make it necessary to create some integration code for certain platforms and containers (e.g., the JVM, by default, assumes that it can resolve the common name as a host name). The downside is that such an approach would open the possibility for man in the middle attacks. Only in combination with client certificates this can be prevented (alas, this might need some more adaption on the server side).

Finally, the certificates on both, the server and the target side, respectively, would need to be in a chain of trust. Assuming this precondition holds, the only way to eavesdrop would then be to exploit one of the certificate's private key (e.g., via disassembling the target by an attacker that has physical access or by means of gaining access to the target via a different vulnerability). Such a key could be blacklisted by adding it to the certificate revocation list upon discovery of its exploitation.

Encryption

The physical access threat makes it possible that attackers might get hold of data (like installed bundles). Https and certificates can prevent eavesdropping while data is distributed but if an attacker can get hold of the target or a relay server it is still possible to access the data. As mentioned above, for the target the only way to prevent this would be hardware supported encryption but for relay servers it is sufficient to encrypt the data itself. We might need to support this eventually but it is not looked into further in this analysis.

Certificate based Flow Analysis

All entities (the server, the client, the relay server, and the target), have a CRL and a keystore; the former contains revoked certificates and the later the known and trusted certificate authorities. In general, for all involved certificates, for a certificate to be valid it has to be the case that it is in a chain-of-trust relation to at least one of the trusted certificate authorities and is not revoked. Furthermore, there exists a special trusted certificate known as the server authority and vice versa for the target and client. The interaction between the entities is via HTTPS and needs a valid server and client certificate. The common name of the certificate represents the target, client, or server id, respectively. As a further restriction the server certificate has to be in a chain of trust to the server certificate authority, the client certificate has to be in a chain of trust to the client certificate authority, and the target certificate has to be in a chain of trust to the target certificate authority. The data exchanged between the entities needs to be signed by the respective counterpart certificate authority. For example, a deployment package send from the server to the target needs to be signed by a valid certificate that is in a chain of trust to the server certificate authority and auditlog entries send from the target to the server must be signed by its target certificate. In other words, the signer needs to be the one that created the specific data. CLR and keystore can be treated as yet another object repository (because they need to be signed) – hence, they can be synced from a server to clients, relay servers, and subsequently, targets.

Conclusion

The set-up takes aforementioned countermeasure to the identified threat into account. The https connection ensures the confidentiality via encryption. Due to the server and client certificate connection authentication and authorization are addressed. The requirement of separately signed content provides integrity and non repudiation in the absence of compromised certificate private keys. Certificates with known exploited keys can be revoked by adding them to the CRLs. Authority derives from the chain of trust relation to the server and target certificate authority.