IDSCP2 Transport Layer
The IDSCP2 transport layer is a flexible and message agnostic transport layer, creating a TLS based tunnel and providing a state machine which enables flexible extension for various attestation mechanisms. The transport layer protocol negotiations have to be completed successfully before allowing the application layer to take over.
The heart of the IDSCP2 protocol is an event-based finite state machine that consists of several states and transitions, which are triggered by events.
In the following, you can see a simplified version of the IDSCP2 state machine:
The goal of the IDSCP2 handshake is to reach STATE_ESTABLISHED, which allows the IDSCP2 communication with the remote peer. To achieve this state, first the handshake has to be started by the upper layer, valid DATs have to be exchanged and verified, and finally the Remote Attestation (RA) drivers have to verify each other's trusted state.
During the handshake as well as after the protocol is in STATE_ESTABLISHED, re-attestations and fresh DAT requests can be triggered to keep the communication trusted over time. Thus, many transitions in the state machine were introduced to support both RA and DAT timeouts, upper layer re-attestation requests, as well as re-attestation- and fresh-DAT-request from the remote peer in each state.
In the following all states, events and timeouts are listed with a short description:
FSM states
STATE_CLOSED, which should be divided into the final state, STATE_CLOSED_LOCKED, and into the init state, STATE_CLOSED_UNLOCKED.
STATE_WAIT_FOR_HELLO, which waits for the IDSCP_HELLO of the remote peer
STATE_WAIT_FOR_RA, which waits for the result of the RA_PROVER and RA_VERIFIER drivers
STATE_WAIT_FOR_RA_PROVER, which waits for the result of the RA_PROVER driver
STATE_WAIT_FOR_RA_VERIFIER, which waits for the result of the RA_VERIFIER driver
STATE_WAIT_FOR_DAT_AND_RA, which waits for a fresh DAT of the remote peer, as well as for the RA_PROVER driver. After a valid DAT has been received, the RA_VERIFIER will be started for re-attestation.
STATE_WAIT_FOR_DAT_AND_RA_VERIFIER, which waits for a fresh DAT of the remote peer. After a valid DAT has been received, the RA_VERIFIER will be started for re-attestation.
STATE_WAIT_FOR_ACK, which waits for the ACK of the previous message.
STATE_ESTABLISHED, which allows IDSCP2-secure communication with the remote peer.
FSM Events
In each of the above mentioned states, each possible FSM event should be handled. The FSM events are structured into the following categories:
4 UPPER_EVENTS: Events from the User / Upper layer (e.g., ReRa, SendData)
6 Remote Attestation Events (RA_EVENTS): Events from the RaVerifier- and RaProverDriver (RA_OK, RA_FAILURE, RA_MSG)
10 Secure Channel Events (SC_EVENTS): Events from the underlying secure channel (Error, IDSCP2 messages from the remote peer)
4 TIMEOUT_EVENTS: Events triggered by Timer Routines (Handshake Timeout, RA Driver Timeouts, DAT Timeout, Ack Timeout)
In total, there are 24 theoretically possible events per state, which makes in sum 240 transitions (10 states times 24 possible events). However, there is a significant number of events per state that can to be ignored (e.g., almost all events in the final STATE_CLOSED_LOCKED) which reduces the transitions to be implemented by about half of the theoretical 240. Please note that ignoring important events in specific states can lead to security vulnerabilities. Thus, you can find a list of important events for every state below in chapter "Detailed FSM state description".
In detail, the FSM includes the following 24 events:
UPPER_START_HANDSHAKE: Start the IDSCP2 handshake for a fresh Idscp2Connection
UPPER_CLOSE: Close the Idscp2Connection and lock the FSM forever
UPPER_SEND_DATA: Send IDSCP_DATA (application data) to the remote peer
UPPER_RE_RA: Repeat the RA verification of the remote peer
RA_VERIFIER_OK: RA verification of the remote peer has succeed
RA_VERIFIER_FAILED: RA verification of the remote peer has failed
RA_VERIFIER_MSG: RA verifier driver has new data for the counterpart remote RA prover driver
RA_PROVER_OK: RA prover has succeed
RA_PROVER_FAILED: RA prover has failed
RA_PROVER_MSG: RA prover driver has new data for the counterpart remote RA verifier driver
SC_ERROR: Secure channel failed (e.g., socket IO error)
SC_IDSCP_HELLO: Secure channel received IDSCP_HELLO from remote peer
SC_IDSCP_CLOSE: Secure channel received IDSCP_CLOSE from remote peer
SC_IDSCP_DAT: Secure channel received IDSCP_DAT from remote peer
SC_IDSCP_DAT_EXPIRED: Secure channel received IDSCP_DAT_EXPIRED from remote peer
SC_IDSCP_RA_PROVER: Secure channel received IDSCP_RA_PROVER from remote peer
SC_IDSCP_RA_VERIFIER: Secure channel received IDSCP_RA_VERIFIER from remote peer
SC_IDSCP_RE_RA: Secure channel received IDSCP_RE_RA from remote peer
SC_IDSCP_DATA: Secure channel received IDSCP_DATA from remote peer
SC_IDSCP_ACK: Secure channel received IDSCP_ACK from remote peer
HANDSHAKE_TIMEOUT: A handshake timeout occurred. Lock the FSM forever
DAT_TIMEOUT: A DAT timeout occurred, request a new DAT from remote peer
RA_TIMEOUT: A RA timeout occurred, request re-attestation
ACK_TIMEOUT: A ACK timeout occurred, send IDSCP_DATA again
Timeouts
The following timeouts exists:
RA Timeout: This timeout occurs when the trust interval has been expired, and a new re-attestation of the remote peer should be requests.
DAT Timeout: This timeout occurs when the DAT of the remote peer has been expired
Handshake Timeout: This timeout occurs when the handshake activity takes to long. It is suggested to provide own handshake timers per RA driver, such that you can restrict the time a RA driver has to prove its trust.
Ack Timeout: This timeout occurs when no IDSCP_ACK has been received for the last sent IDSCP_DATA message. It should trigger a repetition of sending the message.
Detailed FSM state description
In the following, each state and its important events are discussed and what transitions the specific event will trigger. If any unexpected error occurs, the FSM should go into STATE_CLOSED_LOCKED.
STATE_CLOSED_LOCKED
This state is actually the final state of the FSM without any outgoing transition. If this state has been entered once, it can never ever reach another state again. Therefore, an implementation in this state has to ignore every event. This state should be entered from any other state whenever an error occurred, or the connection lose its trust due to an invalid DAT, or a failed re-attestation.
STATE_CLOSED_UNLOCKED
This state is actually the init state of the FSM. The only event that should be recognized in this state is the UPPER_START_HANDSHAKE event, which should send an IDSCP_HELLO to the remote peer via the secure channel and should then go into the state STATE_WAIT_FOR_HELLO.
STATE_WAIT_FOR_HELLO
This state waits for the remote peer's IDSCP_HELLO, which contains the DAT and the RA suites of the remote peer. When the SC_IDSCP_HELLO has been received, both connectors have to verify the remote DAT via the DAPS driver, calculate the RA mechanisms and start the RA drivers. A peer always decides which RA mechanism should be used to verify the remote peer. Thus, the outer loop in the matching algorithm always has to loop through the RA_VERIFIERS, while the inner loop goes through the counterpart RA_PROVERS. In this state the handshake timer should be active.
The following events must be handled as described while all other events should be ignored:
HANDSHAKE_TIMEOUT: send IDSCP_CLOSE and go to STATE_CLOSED_LOCKED
UPPER_CLOSE: send IDSCP_CLOSE and go to STATE_CLOSED_LOCKED
SC_ERROR: go to STATE_CLOSED_LOCKED
SC_IDSCP_CLOSE: go to STATE_CLOSED_LOCKED
SC_IDSCP_HELLO: If the DAT is valid, start the DAT timeout, calculate the RA mechanisms, start the RA drivers, start the driver handshake timeouts and go to STATE_WAIT_FOR_RA. Otherwise, send IDSCP_CLOSE and go to STATE_CLOSED_LOCKED
STATE_WAIT_FOR_RA
This state waits for the results of the RA_PROVER, as well as the RA_VERIFIER driver. The driver handshake timer, as well as the DAT timer should be active.
The following events must be handled as described while all other events should be ignored:
HANDSHAKE_TIMEOUT: send IDSCP_CLOSE and go to STATE_CLOSED_LOCKED
DAT_TIMEOUT: send IDSCP_DAT_EXPIRED and go to STATE_WAIT_FOR_DAT_AND_RA
UPPER_CLOSE: send IDSCP_CLOSE and go to STATE_CLOSED_LOCKED
RA_PROVER_OK: cancel the RA_PROVER handshake timer and go to STATE_WAIT_FOR_RA_VERIFIER
RA_PROVER_MSG: send IDSCP_RA_PROVER and stay in STATE_WAIT_FOR_RA
RA_PROVER_FAILED: send IDSCP_CLOSE and go to STATE_CLOSED_LOCKED
RA_VERIFIER_OK: cancel the RA_VERIFIER handshake timer and go to STATE_WAIT_FOR_RA_PROVER
RA_VERIFIER_MSG: send IDSCP_RA_VERIFIER and stay in STATE_WAIT_FOR_RA
RA_VERIFIER_FAILED: send IDSCP_CLOSE and go to STATE_CLOSED_LOCKED
SC_ERROR: go to STATE_CLOSED_LOCKED
SC_IDSCP_CLOSE: go to STATE_CLOSED_LOCKED
SC_IDSCP_DAT_EXPIRED: send a fresh IDSCP_DAT, restart RA_PROVER and stay in STATE_WAIT_FOR_RA
SC_IDSCP_RA_PROVER: delegate to local RA_VERIFIER driver and stay in STATE_WAIT_FOR_RA
SC_IDSCP_RA_VERIFIER: delegate to local RA_PROVER driver and stay in STATE_WAIT_FOR_RA
SC_IDSCP_ACK: if this ACK belongs to the expected message regarding the alternating bit protocol, clear the ack flag and alternate the next_send_alternating_bit, otherwise ignore. Stay in STATE_WAIT_FOR_RA
STATE_WAIT_FOR_RA_VERIFIER
This state waits for the result of the RA_VERIFIER driver. The RA_VERIFIER handshake timer, as well as the DAT timer should be active.
The following events must be handled as described while all other events should be ignored:
HANDSHAKE_TIMEOUT: send IDSCP_CLOSE and go to STATE_CLOSED_LOCKED
DAT_TIMEOUT: send IDSCP_DAT_EXPIRED and go to STATE_WAIT_FOR_DAT_AND_RA_VERIFIER
UPPER_CLOSE: send IDSCP_CLOSE and go to STATE_CLOSED_LOCKED
RA_VERIFIER_OK: cancel the RA_VERIFIER handshake timer and go to STATE_ESTABLISHED or STATE_WAIT_FOR_ACK depending on if the ack flag is set or not.
RA_VERIFIER_MSG: send IDSCP_RA_VERIFIER and stay in STATE_WAIT_FOR_RA_VERIFIER
RA_VERIFIER_FAILED: send IDSCP_CLOSE and go to STATE_CLOSED_LOCKED
SC_ERROR: go to STATE_CLOSED_LOCKED
SC_IDSCP_CLOSE: go to STATE_CLOSED_LOCKED
SC_IDSCP_DAT_EXPIRED: send a fresh IDSCP_DAT, restart RA_PROVER and stay in STATE_WAIT_FOR_RA
SC_IDSCP_RA_PROVER: delegate to local RA_VERIFIER driver and stay in STATE_WAIT_FOR_RA_VERIFIER
SC_IDSCP_RE_RA: restart the RA_PROVER driver and go to STATE_WAIT_FOR_RA
SC_IDSCP_ACK: if this ACK belongs to the expected message regarding the alternating bit protocol, clear the ack flag and alternate the next_send_alternating_bit, otherwise ignore. Stay in STATE_WAIT_FOR_RA_VERIFIER
STATE_WAIT_FOR_RA_PROVER
This state waits for the result of the RA_PROVER driver. The RA_PROVER handshake timer, as well as the DAT timer, and the RA timer should be active. In this state, the remote peer has already been verified.
The following events must be handled as described while all other events should be ignored:
HANDSHAKE_TIMEOUT: send IDSCP_CLOSE and go to STATE_CLOSED_LOCKED
RA_TIMEOUT: request re-attestation by sending IDSCP_RE_RA, start the RA_VERIFIER and its handshake timeout and go to STATE_WAIT_FOR_RA
DAT_TIMEOUT: send IDSCP_DAT_EXPIRED and go to STATE_WAIT_FOR_DAT_AND_RA
UPPER_CLOSE: send IDSCP_CLOSE and go to STATE_CLOSED_LOCKED
UPPER_RE_RA: request re-attestation by sending IDSCP_RE_RA, start the RA_VERIFIER and its handshake timeout and go to STATE_WAIT_FOR_RA
RA_PROVER_OK: cancel the RA_PROVER handshake timer and go to STATE_ESTABLISHED or STATE_WAIT_FOR_ACK depending on if the ack flag is set or not.
RA_PROVER_MSG: send IDSCP_RA_PROVER and stay in STATE_WAIT_FOR_RA_PROVER
RA_PROVER_FAILED: send IDSCP_CLOSE and go to STATE_CLOSED_LOCKED
SC_ERROR: go to STATE_CLOSED_LOCKED
SC_IDSCP_CLOSE: go to STATE_CLOSED_LOCKED
SC_IDSCP_RE_RA: restart the RA_PROVER driver and stay in STATE_WAIT_FOR_RA_PROVER
SC_IDSCP_DAT_EXPIRED: send a fresh IDSCP_DAT, restart RA_PROVER and stay in STATE_WAIT_FOR_RA_PROVER
SC_IDSCP_RA_VERIFIER: delegate to local RA_PROVER driver and stay in STATE_WAIT_FOR_RA_PROVER
SC_IDSCP_ACK: if this ACK belongs to the expected message regarding the alternating bit protocol, clear the ack flag and alternate the next_send_alternating_bit, otherwise ignore. Stay in STATE_WAIT_FOR_RA_PROVER
STATE_WAIT_FOR_DAT_AND_RA_VERIFIER
In this state the local peer first has to wait for a fresh valid DAT from the remote peer. Only the handshake timer should be active. No RA driver should be active.
The following events must be handled as described while all other events should be ignored:
HANDSHAKE_TIMEOUT: send IDSCP_CLOSE and go to STATE_CLOSED_LOCKED
UPPER_CLOSE: send IDSCP_CLOSE and go to STATE_CLOSED_LOCKED
SC_ERROR: go to STATE_CLOSED_LOCKED
SC_IDSCP_CLOSE: go to STATE_CLOSED_LOCKED
SC_IDSCP_DAT_EXPIRED: send a fresh IDSCP_DAT, start the RA_PROVER driver and go to STATE_WAIT_FOR_DAT_AND_RA
SC_IDSCP_DAT: if the DAT is valid, start the DAT timeout, start the RA_VERIFIER driver and go to STATE_WAIT_FOR_RA_VERIFIER
SC_IDSCP_RE_RA: start the RA_PROVER driver and go to STATE_WAIT_FOR_DAT_AND_RA
SC_IDSCP_ACK: if this ACK belongs to the expected message regarding the alternating bit protocol, clear the ack flag and alternate the next_send_alternating_bit, otherwise ignore. Stay in STATE_WAIT_FOR_DAT_AND_RA_VERIFIER
STATE_WAIT_FOR_DAT_AND_RA
This state is similar to the STATE_WAIT_FOR_DAT_AND_RA_VERIFIER, but the RA_PROVER driver is active. Only the handshake timer should be active.
The following events must be handled as described while all other events should be ignored:
HANDSHAKE_TIMEOUT: send IDSCP_CLOSE and go to STATE_CLOSED_LOCKED
UPPER_CLOSE: send IDSCP_CLOSE and go to STATE_CLOSED_LOCKED
RA_PROVER_OK: cancel the RA_PROVER handshake timer and go to STATE_WAIT_FOR_DAT_AND_RA
RA_PROVER_MSG: send IDSCP_RA_PROVER and stay in STATE_WAIT_FOR_DAT_AND_RA
RA_PROVER_FAILED: send IDSCP_CLOSE and go to STATE_CLOSED_LOCKED
SC_ERROR: go to STATE_CLOSED_LOCKED
SC_IDSCP_CLOSE: go to STATE_CLOSED_LOCKED
SC_IDSCP_DAT_EXPIRED: send a fresh IDSCP_DAT, restart the IDSCP_RA_PROVER and stay in STATE_WAIT_FOR_DAT_AND_RA
SC_IDSCP_DAT: if the DAT is valid, start the DAT timeout, start the RA_VERIFIER driver and go to STATE_WAIT_FOR_RA
SC_IDSCP_RA_VERIFIER: delegate to local RA_PROVER driver and stay in STATE_WAIT_FOR_DAT_AND_RA
SC_IDSCP_RE_RA: restart the RA_PROVER driver and stay in STATE_WAIT_FOR_DAT_AND_RA
SC_IDSCP_ACK: if this ACK belongs to the expected message regarding the alternating bit protocol, clear the ack flag and alternate the next_send_alternating_bit, otherwise ignore. Stay in STATE_WAIT_FOR_DAT_AND_RA
STATE_ESTABLISHED
This state is the goal state, which allows secure and trusted communication between two peers. The DAT timeout and the RA timeout should be active in this state.
The following events must be handled as described while all other events should be ignored:
UPPER_CLOSE: send IDSCP_CLOSE and go to STATE_CLOSED_LOCKED
UPPER_RE_RA: send IDSCP_RE_RA, start RA_VERIFIER driver and RA_VERIFIER handshake timer and go to STATE_WAIT_FOR_RA_VERIFIER
UPPER_SEND_DATA: send IDSCP_DATA with next_send_alternating bit, message, set ACK flag, start ACK timer and go to STATE_WAIT_FOR_ACK
RA_TIMEOUT: send IDSCP_RE_RA, start RA_VERIFIER driver and RA_VERIFIER handshake timer and go to STATE_WAIT_FOR_RA_VERIFIER
DAT_TIMEOUT: cancel RA timer, send IDSCP_DAT_EXPIRED and go to STATE_WAIT_FOR_DAT_AND_RA_VERIFIER
SC_ERROR: go to STATE_CLOSED_LOCKED
SC_IDSCP_CLOSE: go to STATE_CLOSED_LOCKED
SC_DAT_EXPIRED: send a fresh IDSCP_DAT, restart the local RA_PROVER and go to STATE_WAIT_FOR_RA_PROVER
SC_RE_RA: start the RA_PROVER driver and go to STATE_WAIT_FOR_RA_PROVER
SC_IDSCP_DATA: If the received alternating bit within the IDSCP_DATA is not equal to the expected_alternating bit, ignore the message. Otherwise, send an IDSCP_ACK containing the expected_alternating bit to the remote peer, then alternate the expected_alternating bit and pass the message to the upper layer.
STATE_WAIT_FOR_ACK
This state is a kind of established state, however before new messages can be sent, the peers have to wait for the expected IDSCP_ACK that belongs to our previous sent message. This is required to guarantee that packages cannot be lost during a re-attestation of the trusted state. The IDSCP_ACK follows the AlternatingBit protocol, which is explained below. An ACK timer will be active to trigger repetition of sending data when no ACK has been received within a specified interval. Further, the RA timer and the DAT timer should be active.
The following events must be handled as described while all other events should be ignored:
UPPER_CLOSE: send IDSCP_CLOSE and go to STATE_CLOSED_LOCKED
UPPER_RE_RA: cancel ACK timer, send IDSCP_RE_RA, start RA_VERIFIER driver and RA_VERIFIER handshake timer and go to STATE_WAIT_FOR_RA_VERIFIER
RA_TIMEOUT: cancel ACK timer, send IDSCP_RE_RA, start RA_VERIFIER driver and RA_VERIFIER handshake timer and go to STATE_WAIT_FOR_RA_VERIFIER
DAT_TIMEOUT: cancel RA timer and ACK timer, send IDSCP_DAT_EXPIRED and go to STATE_WAIT_FOR_DAT_AND_RA_VERIFIER
ACK_TIMEOUT: repeat sending the cached IDSCP_DATA, restart the ACK timer and stay in STATE_WAIT_FOR_ACK
SC_ERROR: go to STATE_CLOSED_LOCKED
SC_IDSCP_CLOSE: go to STATE_CLOSED_LOCKED
SC_DAT_EXPIRED: cancel ACK timer, send fresh IDSCP_DAT, restart the RA_PROVER driver and go to STATE_WAIT_FOR_RA_PROVER
SC_RE_RA: cancel ACK timer, start the RA_PROVER driver and go to STATE_WAIT_FOR_RA_PROVER
SC_IDSCP_DATA: If the received alternating bit within the IDSCP_DATA is not equal to the expected_alternating bit, ignore the message. Otherwise, send an IDSCP_ACK containing the expected_alternating bit to the remote peer, then alternate the expected_alternating bit and pass the message to the upper layer.
SC_IDSCP_ACK: if this ACK belongs to the expected message regarding the alternating bit protocol, clear the ack flag, alternate the next_send_alternating_bit and go to STATE_ESTABLISHED, otherwise ignore it and stay in STATE_WAIT_FOR_ACK
Alternating Bit Protocol
The alternating bit protocol is responsible for guaranteeing that no IDSCP_DATA can get lost during a re-attestation procedure. Each peer has one next_send_alternating_bit for sending IDSCP_DATA without loss and one expected_alternating_bit for receiving IDSCP_DATA in the right order.
At the beginning, both bits must be initialized with zero. When sending new IDSCP_DATA, the next_send_alternating_bit is placed into the IDSCP_DATA message. It is only then alternated, when an IDSCP_ACK with this same next_send_alternating_bit has been received.
The expected_alternating_bit is used for checking if a new received IDSCP_DATA message has correctly been ordered and no other IDSCP_DATA between has been lost between. When the bit of the received IDSCP_DATA matches the expected_alternating_bit, an IDSCP_ACK is sent with this expected_alternating_bit and will be alternated afterwards.
Ra Mechanism Calculation
As already described above, each peer has to decide its local RA_VERIFIER mechanism, which is then used by the local RA_VERIFIER, as well as by the corresponding remote RA_PROVER to verifier that the remote peer is in a trusted state. The local RA suites are passed by the user to the IDSCP core, while the remote suites are received via the IDSCP_HELLO, which holds a list of supported and expected RA mechanisms. These lists are ordered by the priority, which means that early entries should be preferred.
An example for the implementation can be found here
IDSCP2 message format
The IDSCP2 messages have been built via Protobuf version 3. The following format must be respected in all implementations:
Last updated