Table 5: Data for comparison framework.

PropertyDescription

Adaptation
Object to adaptKey agreement algorithm
Adaptation timingStart-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 analysesMonitors: 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 executionThe 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.
KnowledgeKnowledge source is not described.
Self-propertiesContext awareness: location and device constraints.

Security
AttributesConfidentiality and integrity during the communication.
MechanismsKey agreement algorithm
One-, two-, and three-pass EC-MQW
Protected assetData in communication channel.
ThreatsThreats for the communication confidentiality and integrity.

Lifecycle
ArchitectureCaSM (Context-aware Security Manager) implemented as a layer between a user’s application and security protocol. Architecture for the adaptation loop is not described.
ExtensibilityThe approach concentrates on key agreement with the specific crypto system. However, CaSM can be also applied to adapt to other security mechanisms.
FlexibilityThe approach is not coupled to specific environment or usage scenario.
ReusabilityThe CaSM component (layer) can be reused in different applications.
MaturityThe 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.