# Feasibility Assessment of a Fine-Grained Access Control Model on Resource Constrained Sensors
## 3 Access Control Model
### Authorization Policy Language and Codification
#### 3.2.2 Measurable Policy Instance Examples
When it receives and checks the identity of the sending CDS of such a logging message, it updates the records and acknowledges back positively in a response message \(HID\_R\_ACK\), thereby allowing the CDS to flush any related storage. * Hidra in the subject side (_HidraS_) initiates the full sequence of the message exchange, as shown in Listing 9. It is implemented following a multi-step workflow. First, when no TGT has been obtained yet, it starts the authentication against the ANS in the ACS to obtain a TGT. It stores the nonces and key (\(Nonce_{S,CM}\) and \(K_{S,CM}\)) required for the next service ticket request to the CM in the ACS. Second, when attempting to achieve security association establishment (SAE) with a CDS, HidraS sends a request of the service ticket to the CM using previous values to generate a message authenticator string. When it receives the response from the CM, it first parses and checks the validity of the addressed destination. Second, it deciphers the \(K_{S,R}\) and some other nonces for freshness validation
and further CDS addressing \(Nonce_{S,R}\). Third, it composes an access request for the CDS including the obtained service ticket and a message authenticator ciphered with \(K_{S,R}\), and the module sends it. When it receives the response from the CDS, the module deciphers it and checks both the validity of the response with respect to the request and the session with respect to the service ticket. In the positive case, the security association is established, and the subject obtains a \(Subkey\) shared with the CDS, ready to be used in further access requests. From then on, and whenever it is locally authorized, any application on the subject side can access the resources on the CDS through the established secure session. ``` IfICTnotavailablethen{  MCT request message composition & transmission  WaitforTCTresponsemess reception&validation ifvalidIDSthen{  MCT storage  Deployer enhanced data block with \(K_  
* When an indication message \(HID\_CM\_IND\) is received from the ACS, it is first parsed, and both the addressed CDS as well as the MAC are validated. Then, the received key value \(K_{S,CM}^{j}\) is validated and attempted for five iterations in unsuccessful cases. In the case of five unsuccessful trials using the received key value or when the chain is finished, a message \(HID\_CM\_IND\_REQ\) is sent to the ACS to request a new sequence. In the positive case, the new key value as well as the subject identity and the shared \(Nonce_{S,R}\) are stored for further message validation. Then, the module goes to the idle state. * When a response message \(HID\_CM\_IND\_REP\) is received from the ACS initiating the key value chain, the message is validated after checking the identity of the CDS and \(Nonce_{3}\); then, the received MAC is also confirmed. In the positive case, the new sequence key value is used to check the validity of the previous indication message from the ACS. Then, the module goes to the idle state. * When an access request message \(HID\_S\_R\_REQ\) is received from the subject, the received ticket is first deciphered with \(K_{R}\). The enclosed \(K_{S,R}\) is used to decipher the message authenticator that conveys the \(Nonce_{S,R}\) nonce to check the peers and the sequence of the messages. In the positive case, local authorization is enforced according to the related policy instance; in addition, the security association is established, and the shared \(Subkey\) is stored. Then, the response message to the subject is composed and sent. Finally, a new message for the ACS is composed, therein conveying the detailed log of the access attempt from the subject, which was previously ciphered with the \(K_{R}\) key. Then, the module goes to the idle state. * When a log acknowledgment is received from the ACS, it is first parsed, the CDS id is checked, and the MAC is validated. In the positive case, log records can be flushed in the CDS, and the modules goes to the idle state. During the development and codification, some design decisions have been made.