|
| Property | Description |
|
| Adaptation |
| Object to adapt | Key agreement algorithm |
| Adaptation timing | Start-up time adaptation, that is, at the beginning of each communication session. Considering proactive/reactive aspect is not applicable for start-up time adaptation. |
| Monitoring and analyses | Monitors: location (scenario/scene) and device’s capability. It is assumed that particular attacks are not relevant in certain places, that is, analysed beforehand. |
| Planning and execution | The used key agreement algorithm depends on location and constraints of the device, that is, context information from the CaSM. The actions, which will be performed in different situations, are selected beforehand (hard coded actions), that is, static planning. |
| Knowledge | Knowledge source is not described. |
| Self-properties | Context awareness: location and device constraints. |
|
| Security |
| Attributes | Confidentiality and integrity during the communication. |
| Mechanisms | Key agreement algorithm
One-, two-, and three-pass EC-MQW |
| Protected asset | Data in communication channel. |
| Threats | Threats for the communication confidentiality and integrity. |
|
| Lifecycle |
| Architecture | CaSM (Context-aware Security Manager) implemented as a layer between a user’s application and security protocol. Architecture for the adaptation loop is not described. |
| Extensibility | The approach concentrates on key agreement with the specific crypto system. However, CaSM can be also applied to adapt to other security mechanisms. |
| Flexibility | The approach is not coupled to specific environment or usage scenario. |
| Reusability | The CaSM component (layer) can be reused in different applications. |
| Maturity | The approach is not validated. In addition, the paper, which presents the approach, is the only available information source. Hence, guidelines how to implement the adaptation approach is not available. There is not a community behind the approach. |
|
