ace-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r810675 - in /websites/staging/ace/trunk/content: ./ dev-doc/analysis/security-analysis-flow.svg dev-doc/analysis/security-analysis.html dev-doc/analysis/src/ dev-doc/analysis/src/security-analysis-flow.graffle
Date Fri, 30 Mar 2012 07:44:58 GMT
Author: buildbot
Date: Fri Mar 30 07:44:57 2012
New Revision: 810675

Staging update by buildbot for ace

    websites/staging/ace/trunk/content/dev-doc/analysis/security-analysis-flow.svg   (with
  (with props)
    websites/staging/ace/trunk/content/   (props changed)

Propchange: websites/staging/ace/trunk/content/
--- cms:source-revision (original)
+++ cms:source-revision Fri Mar 30 07:44:57 2012
@@ -1 +1 @@

Added: websites/staging/ace/trunk/content/dev-doc/analysis/security-analysis-flow.svg
Binary file - no diff available.

Propchange: websites/staging/ace/trunk/content/dev-doc/analysis/security-analysis-flow.svg
    svn:mime-type = image/svg+xml

Added: websites/staging/ace/trunk/content/dev-doc/analysis/security-analysis.html
--- websites/staging/ace/trunk/content/dev-doc/analysis/security-analysis.html (added)
+++ websites/staging/ace/trunk/content/dev-doc/analysis/security-analysis.html Fri Mar 30
07:44:57 2012
@@ -0,0 +1,205 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html lang="en">
+  <head>
+    <title>Security Analysis</title>
+    <meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
+    <meta property="og:image" content="" />
+    <link rel="stylesheet/less" type="text/css" href="/lib/bootstrap.less">
+    <link href="/css/prettify.css" rel="stylesheet">
+    <script src="/js/less-1.2.1.min.js" type="text/javascript"></script>
+    <script src=""></script>
+    <script src="/js/prettify.js"></script>
+    <script src="/js/bootstrap-alert.js"></script>
+    <script src="/js/bootstrap-dropdown.js"></script>
+    <script src="/js/bootstrap-tooltip.js"></script>
+    <script src="/js/bootstrap-alerts.js"></script>
+    <script src="/js/bootstrap-modal.js"></script>
+    <script src="/js/bootstrap-transition.js"></script>
+    <script src="/js/bootstrap-button.js"></script>
+    <script src="/js/bootstrap-popover.js"></script>
+    <script src="/js/bootstrap-twipsy.js"></script>
+    <script src="/js/bootstrap-buttons.js"></script>
+    <script src="/js/bootstrap-scrollspy.js"></script>
+    <script src="/js/bootstrap-typeahead.js"></script>
+    <script src="/js/bootstrap-carousel.js"></script>
+    <script src="/js/bootstrap-tab.js"></script>
+    <script src="/js/bootstrap-collapse.js"></script>
+    <script src="/js/bootstrap-tabs.js"></script>
+    <script>
+    $(function () { prettyPrint() })
+    $().dropdown()
+    </script>
+  </head>
+  <body style="padding-top: 50px;">
+    <div class="navbar navbar-fixed-top">
+      <div class="navbar-inner">
+        <div class="container">
+          <a class="brand" href="/index.html">Apache ACE</a>
+          <ul class="nav">
+  <li class="dropdown">
+    <a href="#" class="dropdown-toggle" data-toggle="dropdown">News <b class="caret"></b></a>
+    <ul class="dropdown-menu">
+      <li>
+        <a href="/news.html">News</a>
+      </li>
+      <li>
+        <a href="/on-the-web.html">On the web</a>
+      </li>
+    </ul>
+  </li>
+  <li>
+    <a href="/downloads.html">Downloads</a>
+  </li>
+  <li class="dropdown">
+    <a href="#" class="dropdown-toggle" data-toggle="dropdown">User Documentation <b
+    <ul class="dropdown-menu">
+      <li>
+        <a href="/user-doc/introduction.html">Introduction</a>
+      </li>
+      <li>
+        <a href="/user-doc/getting-started.html">Getting Started</a>
+      </li>
+      <li>
+        <a href="/user-doc/features.html">Features</a>
+      </li>
+      <li>
+        <a href="/user-doc/faq.html">FAQ</a>
+      </li>
+      <li>
+        <a href="/user-doc/support.html">Support</a>
+      </li>
+    </ul>
+  </li>
+  <li class="dropdown">
+    <a href="#" class="dropdown-toggle" data-toggle="dropdown">Developer Documentation
<b class="caret"></b></a>
+    <ul class="dropdown-menu">
+      <li>
+        <a href="/dev-doc/requirements/">Requirements</a>
+      </li>
+      <li>
+        <a href="/dev-doc/architecture.html">Architecture</a>
+      </li>
+      <li>
+        <a href="/dev-doc/analysis/">Analysis</a>
+      </li>
+      <li>
+        <a href="/dev-doc/design/">Design</a>
+      </li>
+      <li>
+        <a href="/dev-doc/coding-standards.html">Coding Standards</a>
+      </li>
+    </ul>
+  </li>
+  <li class="dropdown">
+    <a href="#" class="dropdown-toggle" data-toggle="dropdown">Get Involved <b class="caret"></b></a>
+    <ul class="dropdown-menu">
+      <li>
+        <a href="/get-involved/mailing-lists.html">Mailing Lists</a>
+      </li>
+      <li>
+        <a href="/get-involved/issue-tracking.html">Issue Tracking</a>
+      </li>
+      <li>
+        <a href="/get-involved/source-code.html">Source Code</a>
+      </li>
+      <li>
+        <a href="/get-involved/project-team.html">Project Team</a>
+      </li>
+    </ul>
+  </li>
+  <li class="dropdown">
+    <a href="#" class="dropdown-toggle" data-toggle="dropdown">Wiki <b class="caret"></b></a>
+    <ul class="dropdown-menu">
+      <li>
+        <a href="">Board
Reports <i class="icon-share-alt"></i></a>
+      </li>
+      <li>
+        <a href="">Homepage <i
+      </li>
+    </ul>
+  </li>
+  <li class="dropdown">
+    <a href="#" class="dropdown-toggle" data-toggle="dropdown">Apache <b class="caret"></b></a>
+    <ul class="dropdown-menu">
+      <li>
+        <a href="">Licenses <i class="icon-share-alt"></i></a>
+      </li>
+      <li>
+        <a href="">Security <i class="icon-share-alt"></i></a>
+      </li>
+      <li>
+        <a href="">Sponsorship <i
+      </li>
+      <li>
+        <a href="">Thanks <i class="icon-share-alt"></i></a>
+      </li>
+    </ul>
+  </li>
+        </div>
+      </div>
+    </div>
+    <div class="container">
+      <p><a href="/"><i class='icon-home'></i> Home</a>&nbsp;&raquo&nbsp;<a
href="/dev-doc/">Dev-doc</a>&nbsp;&raquo&nbsp;<a href="/dev-doc/analysis/">Analysis</a></p>
+      <h1>Security Analysis</h1>
+      <div class="clear"></div>
+      <div id="content"><p>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.</p>
+<p>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).</p>
+<p>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.</p>
+<h1 id="threat-scenarios">Threat Scenarios</h1>
+<p>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.</p>
+<li>(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
+<li>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.</li>
+<li>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).</li>
+<li>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.</li>
+<li>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).</li>
+<h1 id="countermeasures">Countermeasures</h1>
+<p>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 o
 f 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
+<p>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.</p>
+<h3 id="authentication">Authentication</h3>
+<p>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.</p>
+<p>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.</p>
+<h3 id="authorization">Authorization</h3>
+<p>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
+<p>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).</p>
+<p>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.</p>
+<h3 id="integrity">Integrity</h3>
+<p>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
+<p>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.</p>
+<p>Furthermore, taking into account relay servers the trusted certificates can be limited
further to for example only allow the actual server certificate.</p>
+<p>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.</p>
+<h3 id="non-repudiation">Non Repudiation</h3>
+<p>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.</p>
+<p>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).</p>
+<p>Furthermore, it will be easy to invalidate data from compromised entities by adding
their certificates to the certificate revocation list.</p>
+<p>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.</p>
+<h3 id="confidentiality">Confidentiality</h3>
+<p>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.</p>
+<p>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
+<p>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.</p>
+<p>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).</p>
+<p>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.</p>
+<h3 id="encryption">Encryption</h3>
+<p>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.</p>
+<h1 id="certificate-based-flow-analysis">Certificate based Flow Analysis</h1>
+<p>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.</p>
+<p><object data="security-analysis-flow.svg" type="image/svg+xml" class="span12"
+<h1 id="conclusion">Conclusion</h1>
+<p>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.</p></div>
+      <hr>
+      <footer>
+        <p>Copyright &#169; 2012 <a href="">The Apache
Software Foundation</a>, Licensed under the <a href="">Apache
License, Version 2.0</a>.<br/>Apache ACE, the Apache ACE logo, Apache and the
Apache feather logo are trademarks of The Apache Software Foundation. All other marks mentioned
may be trademarks or registered trademarks of their respective owners.</p>
+      </footer>
+    </div>
+  </body>

Added: websites/staging/ace/trunk/content/dev-doc/analysis/src/security-analysis-flow.graffle
Binary file - no diff available.

Propchange: websites/staging/ace/trunk/content/dev-doc/analysis/src/security-analysis-flow.graffle
    svn:mime-type = application/xml

View raw message