Main tasks in the development plan
| Threats | Security mechanisms for mitigation |
|---|---|
| T1 | Authentication (username and password, SAML Token etc.), usability of devices |
| T2 | digital signatures e.g. IHE DSG profile, XML signature or XAdES. |
| T3 | digital signatures. Other controls may include malware scanner and automatic updates |
| T4 | Digital signatures e.g. IHE DSG. other controls may include Intrusion detection, Audit logs, and keeping backups |
| T5 | Digital signatures e.g. IHE DSG, XML Signatures |
| T6 | Digital signatures e.g. IHE DSG, XML Signatures could help in protecting the integrity of the forwarded data. |
| T7 | Digital Signatures. other controls may include Audit logs, Separation of duty and backups. |
| T8 | Digital signatures could help to protect the forwarded data and not the data created by actors. other controls may be to keep audit logs. |
| T9 | Digital signatures could help to protect the forwarded data and not the data created by actors. Secure audit trail could helps |
| T10 | Digital signatures may help in detection. Other controls may include continuous testing and focus on software life cycle development. |
| T11 | Authentication and usability of measurement devices. |
| T12 | Anti-virus softwares |
| T13 | "The Android Security" solution - signing the applications, declaring permissions by the application, approving permissions by the user, verifying permissions matching by the buses. The permissions will be specified for Service, Context, Input and Output buses, and will be specified on a per-application and per-user basis. In the Android security is on per-application basis (only one user is assumed to operate a device). As an additional and a first level of defense, some validation can be performed on the uStore. |
| T14 | Adding MAC to the contents of the message before the encryption for the peer-to-peer communication. |
| T15 | Using sequence numbers for messages sent by peers. Each peer should append a sequence number to every message, and increase it after sending the message. To handle situations where peers will fail an be restarted - the peer should append a timestamp when the first sequence number was generated. The first sequence numbers must be chosen randomly by each peer. The timestamp and the sequence number must be signed by MAC and encrypted. Each peer must hold the timestamp and the latest sequence number sent by every peer the last time. When a peer is restarted - it has to ask every peer for their latest sequence number and the timestamp. Otherwise, the following replay attack can be performed: 1. Peer Alice sends a message m to the peer Bob. The peer Bob remembers the sequence number and the timestamp of the message m. 2. The attackers remembers message m. 3. Bob fails (maybe the failure caused by the attacker) and restarts 4. The attacker resends the message m to Bob. The Bob does not have a persistent history and does not know that the message m was sent before his failure. That means that Bob has to query Alice for her latest timestamp and sequence number after restarting |
| T16 | Use SOAP over https, or apply WS-Security solutions. |
| T17 | |
| T18 | In OSGi - use Conditional Permission Admin to control who can register middleware services |
| Threats | Security mechanisms for mitigation |
|---|---|
| T1 | The same solution as for T13. |
| T2 | Apply the existing security solutions of specific WSN technologies, for example of ZigBee. If WSN provides no security measures, it is not clear what could be done in universAAL |
| T3 | Use encryption for inter-node communication. |
| T4 | The same as the previous one. |
| T5 | Data base encryption.IHE Document Encryption Service. |
| T6 | The same as the previous one. |
| T7 | Autentication with user/password with expiration sesion. |
| T8 | Same as previous one. |
| T9 | Same as previous one. |
| T10 | Autentication with user/password. WS-Security/ HTTP-SOAP/ or Protected peer-to-peer tunnel, e.g. by SSL/TLS |
| T11 | Data base encryption.IHE Document Encryption Service. |
| T12 | In OSGi - use Conditional Permission Admin to control who can register middleware services |
Security is a vertical layer in the concrete arechitecture, it influences all parts of the development. Thus, the main work done by this expert group is not the creation of specific security software artefacts. Instead this group works together with other expert groups to increase security aspects in their artefacts. Therefore, these developments in other expert groups are described in the following.
Providing low-level security is the responsibility of the container. Java itself already provides some powerful security mechanisms to allow restricting the capabilities of components as is, for example, used by applets on websites that are executed in a sandbox in a web browser. Those restrictions comprise, e.g., access to the file system of networks. Different Container may provide additional restrictions or define their own set of permissions. OSGi extends the Java security concept by introducing restrictions based on, e.g., bundles, packages, and services. Android defines its own set of permissions.
To enable security in OSGi:
- Create a Java security policy file.
This file contains general restrictions for Java and typically gives all permissions because permissions will be handled internally by OSGi. For example, the file "all.policy" should contain only:
grant {
permission java.security.AllPermission;
};
- Start OSGi with security enabled.
The command line is extended with two additional parameters to follow the given security policy and to enable OSGi security mechanisms:
java -Djava.security.policy=all.policy -Dorg.osgi.framework.security="osgi" -jar bin/felix.jar
- Include OSGi security provider.
Include a security provider in your run configuration. For example, for Apache Felix the security provider can be:
mvn:org.apache.felix/org.apache.felix.framework.security
- Provide permission files for each bundle.
Each bundle should define the set of permissions it needs. This set can be checked during installation of a new bundle and should be accepted from an administrator. The file must be located inside the bundle at "OSGI-INF/permissions.perm". If that file is missing, then all permissions are given per default. For example, the following two lines inside this permissions file will allow the bundle to read files and to import all Java packages (the second line is particularly interesting for OSGi because without this permission it would not be possible to even use the OSGi Activator since this needs an import of org.osgi.framework.BundleActivator):
(java.io.FilePermission "*" "read") (org.osgi.framework.PackagePermission "*" "import")
As described in the Discovery and Peering (D&P) wiki page http://forge.universaal.org/wiki/middleware:Discovery_and_Peering#The_AAL_Spaces, the peers will join and leave from the AAL spaces. Some security requirements emerge from the scenario described from the D&P expert group:
- the solution must exploit on the peering process
- the solution must be founded on realistic assumptions
- the solution must be machine-oriented and automatic
- User interaction should be minimum
- the solution must be highly scalable and allow distributed management
- the solution must facilitate interoperability of previously-unknown nodes
- to adopt solutions for AC based on digital certificates (for authentication, attribute management, and authorization)
- these can be based on x.509v3 or on SAML
- the certificates are much more efficient than other alternatives and can be used even in devices with limited computing capabilities
- to avoid rigid PKI-centred approaches
- to adopt a Proxy-based approach
- this makes the management of security transparent for other UniversAAL components and allows a consistent treatment of security settings
The use of the proxy makes securing communications as transparent as possible (same protocols), moreover the Proxy allows a consistent treatment of security settings and it reduces “insecurity by misconfiguration”. problems. The figure shows how the use of the Proxy allows to have two kinds of communications:
- Insecure protocol: for legacy and old peers
- Secure communication: for new or updated peers
The green blocks represent the current universAAL architecture (middleware) while the orange ones are the applications installed on top of the middleware. The blocks in blue constitute our extension to the current universAAL architecture with the security features.
The uSpace coordinator will manage a set of security policies according to some default configurations shipped with the uSpace it-self or ad-hoc policies configured by an uSpace administrator. The coordinator will manage the secure peering between the coordinator and the peers, the peering phase can rely on insecure protocols (i.e. by using already available protocols like UPnP) or, by converse, by exploiting the secure architecture (blue box). In this case the secure peering includes a negotiation stage that is based in an interactive and privacy-enhanced exchange of credentials between the coordinator and the nodes that try to joint the space. According to the policy specifications and credentials given the secure access is done.
- The ontology model was designed to prevent unauthorized changes to existing ontologies by extracting all setter methods to a new class (Setup). This class is only available for the creator of the ontology.
- The URIs of registered ontology classes are checked for existing classes. Without this check it would be possible to overwrite existing classes, especially the implementation of OWL concepts inside the data representation model, and inject new behaviour or monitor incoming messages.
Security concerns in Context Management mainly involve the protection of the information stored in the Context Store and the forwarded events through the Context Bus. Assuming that the platform will provide enough native security features for the middleware, the context bus and its shared events would be appropriately covered. In addition to that, one of the planned enhancements of the bus is to modify events and strategy to allow the authorization for sharing data based on permissions.
The protection of the context store of the Context History Entrepot (see CM expert group page) however depends on its own implementation. Currently there is no protection at all, other than the file encoding provided by the store engine itself, but it is a planned feature. The main aim is to provide encryption to the stored data. If for whatever reason this is not possible (it wasn´t in the input projects) alternative protection mechanisms must be implemented that provide a similar degree of security.
Finally there are other components of the group, such as platfrom providers or context editors that either need their own specific security restrictions or rely on those provided by the platform itself.
Security in UIM EG is mostly related to the access restriction in terms of helping UI handlers to authenticate (verify person's identity) and authorize (checking is person has access rights to some resource) the user.
Although there are vast number of possibilities how authentication can be addressed. It can be:
a) knowledge based: e.g. username/password or image selection based where user identifies predefined image or gesture based where predefined gesture (on touchscreen) should be done (which works well is user does not have problems with remembering things..)
b) token based: here the drawback is that users can loose the token
c) biometry: refers to methods and techniques that analyze human characteristics in order to recognize a person based on a physiological or behavioral characteristics. Here is maybe less chance for cheating but it is more expensive since it requires additional hardware and additionally specific software. Examples that come in this category are thumbprint, voice based, eye based, ECG based etc.
For the purpose of decoupling authentication and authorization issues a new component ui.security.authorizator was proposed and implemented. For the time being this components deals with knowledge based authentication but in the future (which also depends on the amount of resources that could be spend on the specific hardware and general end user's preferences) other solutions are also feasible.
Security issues in RIEG are related to authentication processes when remotely accessing uSpaces and services. For remote administrating uSpaces and uSpace communication, according to the definition of uSpaces, security tokens can be utilized in order to authenticate and to provide access for secure configuration and remote execution of bundles of an uSpace. Remote services, that in the scope of RI expert group are considered SOAP web services, can provide some authentication mechanisms, like SOAP headers, but usually web service providers expose their services without any security mechanism imposed. The Internet Gateway that will be implemented in RIEG for exchanging data among an uSpace and a SOAP service, will have the capability to authenticate to a web service by handling appropriate SOAP headers.
The following section provides a set of action points in order to clarify where the security and privacy expert group aims to inject functionalities.
The basic goal of ubiquitous middleware is to design simple architecture that operates on enterprise-level information system and fulfill the requirements of end-user effectively. In ubiquitous system environment the biggest challenge is the information sharing among different people who are geographically dispersed and need to work together, which is only possible by smart middleware system. The universAAL middleware must provide to the upper layers the following features:
- Security policies: The universAAL middleware must identify the user or the AAL application, log security relevant events, guarantee users preferences and activities, provide secure communication mechanisms.
- Privacy preserving in services discovery: this is a really challenging development task. When two middleware instances need to privately compute, an intersection of their respective sets of data, one or both parties must obtain the intersection, while neither should learn anything about other set. This is the case when a user enters into an uSpace and wants to discover the provided services, the user wants to receive the services' list but do not disclose his identity and the services which is interested on.
- Consent (or Privacy Policy) Manager: The consent manager stores the patient consent information from the assisted person. There is need to capture patient consent preferences in a standardized way. One of the possible candidates for representing patient consent preference is Implementation Guide for HL7 CDA R2 Consent Directives. This is a replacement for IHE BPPC (Basic Patient Privacy Consent) profile. To protect the patient privacy in an efficient way, the patient consent preferences shall always be attached to individual identifiable data when it travels across the distributed ecosystem of the universAAL, enabling to enforce the patient consent on the consumption point. Another challenge is the provision of the user friendly specification of the patient consent preferences. This could be through a nice user interface or automatic update of patient consent preferences based on the events history.
- Audit logs: The system should audit all the relevant auditable events such as viewer of the resource, failed login, release of the resource etc. IHE ATNA (Audit Trail and Node Authentication) profile provides a standardized way to audit and transport the relevant events to the audit repository.
- Attribute (or Role) based access control: While “access” is the ability to do something with a computer resource, access control is the means by which the ability is explicitly enabled or restricted in some way. In the attribute based access control, the access to the resource is being granted based on the user attributes. One of the examples of the attribute based access control is RBAC (Role Based Access Control), where access decisions are based on the roles that individual users have as part of an organization.
The group has proposed the implementation of IHE document encryption profile (reported in D4.2). It ensures that the data is protected at rest as well as in transit (e2e encryption). IHE is currently working on the document encryption profile. This profile Helps in complying with the meaningful use and privacy legislations (e.g. general encryption clause of the meaningful use)
Technology:
- Cryptographic Message Syntax (CMS), RFC5652, September 2009
- Password-based Encryption for CMS, RFC 3211, December 2001
- Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002
- "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003
- Key management: RecipientInfoType, KeyEncryptionAlgorithmIdentifier
- Hooks for key management
- PKI (certificate-based)
- CMS RecipientInfoType: key transport (KeyTransRecipientInfo)
- Algorithm:RSA Encryption [RFC3370]
- Shared symmetric keys (pre-shared, key retrieval)
- CMS RecipientInfoType: symmetric key-encryption keys (KEKRecipientInfo)
- Algorithm: AES-128 CBC (id-aes128-wrap) [RFC3565]
- Password-based
- CMS RecipientInfoType: password (PasswordRecipientInfo)
- Algorithm: AES-128 CBC as key
- PKI (certificate-based)
The group has proposed the implementation of the consent manager (reported in D4.2). More specifically the group is focusing on implementing the Implementation Guider for HL7 CDA R2 Consent Directive.
This section aims at introducing some relevant security issues in universAAL project by considering two different perspectives: end-user and platform. The end-user security perspective provides a brief overview of the uStore component, by highlighting some possible countermeasures to malicious applications. The platform perspective, instead, provides an overview of the universAAL architecture, by introducing possible platform security features able to guarantee relevant security properties. Also the remote access scenario will be considered.
As described in the DOW document, universAAL project introduces the uStore component acting as AAL application one-stop-shop addressed to AAL users. The uStore aims at implement an easy-to-use service for AAL application diffusion, by adopting an user-experience similar to Apple Store or Nokia’s Ovi store. The uStore is mainly addressed both to end-users and to AAL application providers, the first one will look for available AAL services and will acquire it, while the second one will release AAL applications into the store. It becomes necessary to consider some possible risks related to the interaction between uStore and end-users, more accurately: how end-users can be safe to download applications developed by a specific provider? How applications will interact with end-user devices by means of device resource access or personal information? The cited open questions represent only a subset of the risks bound with uStore component; in order to cover all possible risks, some key aspects will be reported and adopted to drive the design and the implementation of uStore:
- Initial uStore validation: the uStore will perform specific validation step able to guarantee that the ALL application complains to existing constraints. The uStore can exploit the reports provided by Depot Server https://github.com/universAAL/tools/wiki/Developer-Depot-Server component during the overall application development process. The purpose of this aspect is to avoid unchecked AAL application to be downloaded to end-users, generating possible device hangs or unattended application behaviors.
- Digitally signing. The uStore will accept AAL application that have been digitally signed by AAL application providers. The signing can be implemented exploiting public/private signing or other accepted and tested mechanisms, however the purpose is to guarantee:
- No-repudation: once the AAL application has been released into the uStore, AAL application providers can not deny the ownership of the released applications itself
- Certification: every AAL application is shipped with a certificate declaring the identity of developers/application providers. The uStore will verify itself (or through other certification solutions) the digital signature(s) inside the application certification in order to guarantee the certification validity.
- Permissions. AAL applications need access to specific device resources, e.g. gathering sensing data from device sensors, interact with IO peripherals, exploit CPU computations. AAL applications have to make explicit all the required permissions in order to perform specific tasks. This declaration (or manifest) has to be approved by end-users with an explicit feedback (e.g. by means user confirmation). The manifest does not represent a static interaction with end-users (e.g. only at start-up time or only once during application install process), instead the manifest could be dynamic, able to update the required permissions as soon as AAL application need extra privileges. The manifest will be exploited by universAAL platform in order to dynamically allow or deny application device access requests.
At the current project stage, a bus architecture has been chosen in order to enable communications between devices in uSpaces and more generally between application components. The architecture is made of a set of communication buses namely context, service, and UI; each of them adopting specific and extendible communication strategies. Application running in universAAL devices can register to one or more busses, being asynchronously notified as soon as events occur. The UI bus is used to interact with users, typically multi-modal interactions are carried out through this bus. The context bus is an event based bus on which are attached context sources (e.g. the WSNs are attached to this bus or legacy devices), the events generated may be re-elaborated and transformed in high level events (situations) by components subscribed to the bus. The service bus is used to group all the services available in uSpaces. The described scenario has led to possible risks bound with message exchange, in order to introduce more guarantee in bus communications:
- Every message to every bus can contain user ID, provider ID and application ID
- Permissions will be managed based on the combination of the user, provider and application information
- Every service profile, context, and UI event will include the permissions required to access them.
.
FInally also some interoperability issues must be considered from a platform perspective. Actually we can consider two kind of interoperability:
- AAL applications accessing remote application: this scenario comprises AAL applications running into AAL node, that need access to applications deployed in remote systems exposing, e.g., several web services. Such interaction can be implemented by introducing a node local proxy able to let the remote applications act as local to the node. Every proxy call will be redirected to the remote system.
- Remote application accessing bus: this scenario comprises remote systems that need to send messages to AAL-aware nodes. Remote systems send a message to the bus via node gateway and include declared permissions. The AAL-aware node gateway notifies user for the requires and forwards the message into the busses. The gateway can also cache the required permissions in order to optimize message exchanges for future remote communications. The application running on top of AAL-aware node receives notifications from busses and the gateway will handle granting of permissions between bus-remote application.
This set of components is described in the next section.