The Hydra project is co-funded by the 
Articles Hierarchy
Security resolution
Enabling Inclusiveness and Semantic Interoperability are the two main objectives of Hydra. This raises significant challenges both in terms of securing Hydra middleware itself and in terms of enabling security resolution in a heterogeneous environment.
The two main strategies to do this are
1) VIRTUALISATION as the main tool to secure Hydra itself.
Virtualisation is in general the key to security and flexibility in a digital world, but to ensure middleware does not turn into untrustworthy control ware, the core security mechanisms to secure Hydra is to ensure that Hydra DO NOT HAVE TO BE TRUSTED. Fault tolerance principles are built into the core system design. Middleware data sharing as well as device and application representation is ALWAYS virtualised and Hydra middleware have NO ADMINISTRATOR rights or capabilities.
Even if a device has been allowed by access control rules to become part of the logical domain, it does not get access to non-revocable keys or identifiers. As such Hydra does not work with a black/white security model. Devices or applications are not either trusted or not trusted, but always a potential threat that can fail accidentally or deliberately as part of an attack. Devices and applications get access to context specific information and device
representations in a way where all can be revoked.
The purpose of this strictly enforced design principle is security (to ensure Hydra can be trusted even if attacks or errors occur – Hydra does not fail, applications in devices and security policies fail, but Hydra help to enable recoverability), interoperability (Hydra use virtualisation to FORCE delinking the native protocol or device standards from the upper semantic layers) and innovation (by delinking the physical implementation from the logical representation, developers can replace/upgrade/combine devices and application independently).
2) Open Security META STANDARDISATION as the main tool to enable interoperable security and resolution of security.
In Hydra all middleware resolvable application security is supposed to be mapped using devices models and ontologies into an overall security model that is intended to be inclusive and interoperable. Each primitive and mechanism and group of these to meet a security purpose is expanded into all the potential solutions to facilitate comparisons, upgrades and pluralism in facilitating different mechanisms to meet a specific requirement.
Existing security models are primitive reductions of a more overall meta-standard trying to accommodate very different security purposes. They are protocol or technology specific and thereby often security limiting and non-interoperable – deliberate or not intended..
To illustrate just some of the breakthrough differences in security and ICT development, 4 different examples can illustrate the changes introduce with Hydra
Example 1: ICAO Passports using unsecured biometrics and primitive RFID security is NOT secure as both biometrics can be spoofed and the RFID security primitive are weak and NOT interoperable but exclusive as both biometrics is excluding even secured biometrics (revocable) and only RFIDs can implement passports. As such ICAO passports are a security and economic disaster in making, when implemented it is already out-of-date, insufficient to meet the security requirements, unable to upgrade and facilitate gradual introduction of identity security mechanisms meeting requirements of a digital age. Present ICAO Passport standards are what we call exclusive interoperable – only open to exact one technology definition which is both a security disaster and a barrier to innovation to solve the problem.
With Hydra implemented in passport control, security would be delinked from the specific technology and protocol by transformed into semantic proofs where the passport validation can use new or rarely used advanced security primitives in passports being introduced in parallel with old security primitives such as the present “standard” being slowly phased out.
Example 2:In a hospital environment, security is a highly complex question of both enabling access while ensuring strong separation of unrelated processes. The traditional attempt to concentrate data in a central database and then try to resolve access to data in the access control rules is unable to accommodate neither security nor interoperable ease of access. Assuming one standard to deal with these issues are both limiting innovation and certain to be un-secure.
With Hydra this problem is not solved as Hydra does NOT ensure security of devices and applications, but the non-inclusive designs are isolated and the ability to introduce new solutions interoperable with old models facilitated. Instead of getting locked into a Central Command & Control paradigm damaging both security and innovation, new application security mechanisms based on Virtualisation are and can be introduced to meet the very complex requirements on inclusive healthcare support.
Example 3: The term “security” is today monopolised and often dictated upon developers and users by external parties. For instance, some government forces dictate that biometric surveillance is “good” for security, whereas obviously consumer or citizen perspectives would consider the same mechanisms a primary threat to security – simply due to differences in stakeholder perspectives.
With Hydra, the public administration systems will evaluate security capabilities and semantic proofs according to some government approves agency, e.g. FIPS, whereas citizens will evaluate the same capability and semantic proof from an entirely different perspective, e.g. a Consumer Organization evaluation and ranking similar to FIPS but of course with different rankings. If the security resolution is to be successful all involved stakeholders in a transaction will on equal terms have their security requirements fulfilled according to rankings of their choice – or the transaction fail to meet security requirements. A Domain Owner (e.g. a household) can setup and ensure her security requirement of the in-house ambient security environment are balanced in negotiation with a remote application trying to access devices in the home.
An important aspect of this is the introduction and enabling of what in Hydra is known as Dynamic Security. This mean that the security resolution can adapt to changing conditions in the environment such as a a) newly discovered hack to a specific capability downgrading this from good to medium and thus not usable for high-value or sensitive transactions or b) having security adapt to a heightened security threat making more security points require stronger security control for instance to stop a fugitive in a geographically localized area such a a public transport junction without having bureaucratic overkill security requirements normally.
Example 4: The “fax” problem or the “Hen and Egg- problem today make new introductions to the ICT space very hard, especially in security. The existing environment will resist new entrants and even if successful despite these barriers, the new technologies will eventually turn into legacy and a barrier to innovation and security. A good example would be Passports of disabled citizens without biometrics required by the bad ICAO standard, these citizens will need devices adapted to their needs using other security mechanisms such as Biometric Encryption using “Collect and match on card” to authenticate security mechanisms relevant for the present transaction..
With Hydra new mechanisms can be semantically interoperable. One aspect is that they can be introduced much faster to the market place as well as both devices and applications remain operational much longer thereby significantly extending the lifetime of technological inventions, exponentially increasing the number of different applications open for new devices and opening for a much bigger variety in innovations as Hydra solutions are open even for non-intended usage and combinations. This is enabled through mapping and making capabilities and key structures into specific ontologies making comparisons possible.
In addition Hydra aim to be supporting these with dynamic upgrades so that detection of a capability to a device of introduced AFTER the device was put on market can lead to a selective download of upgrade modules so that the combined VIRTUAL DEVICE will have the enhanced features almost as if the feature was included in the original device.
All in all the above examples illustrate and outline how Hydra will introduce a dramatic
but gradual departure from the pre-digital world Command & Control paradigm relying strongly on centralization and surveillance while in reality weakening security of all involved stakeholders as perimeter security deteriorates. In pre-FP7 road-mapping on security & dependability research, SecurIST, this aspect was most clearly singled out as the main guideline.
The dual objectives of securing Hydra aspects and enabling interoperability have very different aspects achieved in a manor than can adapt to change and grow with developer wishes without depending on exclusive non-interoperable design components that turn into legacy and weak security.
Instead Hydra is based on design principles known from Fault Tolerant System for internal integrity especially focusing on visualization and enabling inclusive interoperability with a long range a clear value additions to developers, society and end-users.
The two main strategies to do this are
1) VIRTUALISATION as the main tool to secure Hydra itself.
Virtualisation is in general the key to security and flexibility in a digital world, but to ensure middleware does not turn into untrustworthy control ware, the core security mechanisms to secure Hydra is to ensure that Hydra DO NOT HAVE TO BE TRUSTED. Fault tolerance principles are built into the core system design. Middleware data sharing as well as device and application representation is ALWAYS virtualised and Hydra middleware have NO ADMINISTRATOR rights or capabilities.
Even if a device has been allowed by access control rules to become part of the logical domain, it does not get access to non-revocable keys or identifiers. As such Hydra does not work with a black/white security model. Devices or applications are not either trusted or not trusted, but always a potential threat that can fail accidentally or deliberately as part of an attack. Devices and applications get access to context specific information and device
representations in a way where all can be revoked.
The purpose of this strictly enforced design principle is security (to ensure Hydra can be trusted even if attacks or errors occur – Hydra does not fail, applications in devices and security policies fail, but Hydra help to enable recoverability), interoperability (Hydra use virtualisation to FORCE delinking the native protocol or device standards from the upper semantic layers) and innovation (by delinking the physical implementation from the logical representation, developers can replace/upgrade/combine devices and application independently).
2) Open Security META STANDARDISATION as the main tool to enable interoperable security and resolution of security.
In Hydra all middleware resolvable application security is supposed to be mapped using devices models and ontologies into an overall security model that is intended to be inclusive and interoperable. Each primitive and mechanism and group of these to meet a security purpose is expanded into all the potential solutions to facilitate comparisons, upgrades and pluralism in facilitating different mechanisms to meet a specific requirement.
Existing security models are primitive reductions of a more overall meta-standard trying to accommodate very different security purposes. They are protocol or technology specific and thereby often security limiting and non-interoperable – deliberate or not intended..
To illustrate just some of the breakthrough differences in security and ICT development, 4 different examples can illustrate the changes introduce with Hydra
Example 1: ICAO Passports using unsecured biometrics and primitive RFID security is NOT secure as both biometrics can be spoofed and the RFID security primitive are weak and NOT interoperable but exclusive as both biometrics is excluding even secured biometrics (revocable) and only RFIDs can implement passports. As such ICAO passports are a security and economic disaster in making, when implemented it is already out-of-date, insufficient to meet the security requirements, unable to upgrade and facilitate gradual introduction of identity security mechanisms meeting requirements of a digital age. Present ICAO Passport standards are what we call exclusive interoperable – only open to exact one technology definition which is both a security disaster and a barrier to innovation to solve the problem.
With Hydra implemented in passport control, security would be delinked from the specific technology and protocol by transformed into semantic proofs where the passport validation can use new or rarely used advanced security primitives in passports being introduced in parallel with old security primitives such as the present “standard” being slowly phased out.
Example 2:In a hospital environment, security is a highly complex question of both enabling access while ensuring strong separation of unrelated processes. The traditional attempt to concentrate data in a central database and then try to resolve access to data in the access control rules is unable to accommodate neither security nor interoperable ease of access. Assuming one standard to deal with these issues are both limiting innovation and certain to be un-secure.
With Hydra this problem is not solved as Hydra does NOT ensure security of devices and applications, but the non-inclusive designs are isolated and the ability to introduce new solutions interoperable with old models facilitated. Instead of getting locked into a Central Command & Control paradigm damaging both security and innovation, new application security mechanisms based on Virtualisation are and can be introduced to meet the very complex requirements on inclusive healthcare support.
Example 3: The term “security” is today monopolised and often dictated upon developers and users by external parties. For instance, some government forces dictate that biometric surveillance is “good” for security, whereas obviously consumer or citizen perspectives would consider the same mechanisms a primary threat to security – simply due to differences in stakeholder perspectives.
With Hydra, the public administration systems will evaluate security capabilities and semantic proofs according to some government approves agency, e.g. FIPS, whereas citizens will evaluate the same capability and semantic proof from an entirely different perspective, e.g. a Consumer Organization evaluation and ranking similar to FIPS but of course with different rankings. If the security resolution is to be successful all involved stakeholders in a transaction will on equal terms have their security requirements fulfilled according to rankings of their choice – or the transaction fail to meet security requirements. A Domain Owner (e.g. a household) can setup and ensure her security requirement of the in-house ambient security environment are balanced in negotiation with a remote application trying to access devices in the home.
An important aspect of this is the introduction and enabling of what in Hydra is known as Dynamic Security. This mean that the security resolution can adapt to changing conditions in the environment such as a a) newly discovered hack to a specific capability downgrading this from good to medium and thus not usable for high-value or sensitive transactions or b) having security adapt to a heightened security threat making more security points require stronger security control for instance to stop a fugitive in a geographically localized area such a a public transport junction without having bureaucratic overkill security requirements normally.
Example 4: The “fax” problem or the “Hen and Egg- problem today make new introductions to the ICT space very hard, especially in security. The existing environment will resist new entrants and even if successful despite these barriers, the new technologies will eventually turn into legacy and a barrier to innovation and security. A good example would be Passports of disabled citizens without biometrics required by the bad ICAO standard, these citizens will need devices adapted to their needs using other security mechanisms such as Biometric Encryption using “Collect and match on card” to authenticate security mechanisms relevant for the present transaction..
With Hydra new mechanisms can be semantically interoperable. One aspect is that they can be introduced much faster to the market place as well as both devices and applications remain operational much longer thereby significantly extending the lifetime of technological inventions, exponentially increasing the number of different applications open for new devices and opening for a much bigger variety in innovations as Hydra solutions are open even for non-intended usage and combinations. This is enabled through mapping and making capabilities and key structures into specific ontologies making comparisons possible.
In addition Hydra aim to be supporting these with dynamic upgrades so that detection of a capability to a device of introduced AFTER the device was put on market can lead to a selective download of upgrade modules so that the combined VIRTUAL DEVICE will have the enhanced features almost as if the feature was included in the original device.
All in all the above examples illustrate and outline how Hydra will introduce a dramatic
but gradual departure from the pre-digital world Command & Control paradigm relying strongly on centralization and surveillance while in reality weakening security of all involved stakeholders as perimeter security deteriorates. In pre-FP7 road-mapping on security & dependability research, SecurIST, this aspect was most clearly singled out as the main guideline.
The dual objectives of securing Hydra aspects and enabling interoperability have very different aspects achieved in a manor than can adapt to change and grow with developer wishes without depending on exclusive non-interoperable design components that turn into legacy and weak security.
Instead Hydra is based on design principles known from Fault Tolerant System for internal integrity especially focusing on visualization and enabling inclusive interoperability with a long range a clear value additions to developers, society and end-users.