Security Considerations. The proposed approach relies on building blocks whose security is widely established, namely ECDH [6] and ECQV [10]. Note that these building blocks remain independent in our construction, opposed to being composed, and secret parameters for both schemes are neither exposed to external entities nor used in a way different from their standard usage. In this way, we avoid possible issues that may emerge when mixing blocks whose conjuncted adoption is not universally guaranteed ([9], for instance, shows problems related to the composition of implicit certificates and ECDSA technique). Moreover, ECQV implicit certificates, binding a public key to its owner in a trusted way, make the proposed strategy robust against Man-In-The-Middle (MITM) attacks. Furthermore, the mutual authentication scheme implemented in the second part of the protocol protects the entire approach against replay attacks, and explicitly binds the exchanged cryptographic quantities to the involved peer identities using per-session nonces. It is worth noting that the two authentication messages closely mimic the operation of the Finished message in the Transport Layer Security (TLS) protocol, and therefore inherit the relevant security properties assessed for the TLS protocol [17]. Indeed, each authentication tag is computed by including all the information exchanged in the first two messages (plus the peer identities) and hence protects the entire exchange from MITM modifications. Finally, the designed protocol does not specifically influence (i.e. neither positively or negatively) resilience against physical attacks such as tampering, fault, and side-channel attacks, resilience which is mandated to a careful technical implemen- tation and choice of the involved Elliptic curves. For instance, standard software/hardware-based techniques can be used to mitigate tampering attacks and prevent the physical access to security parameters stored within the device. To prevent fault attacks which force the victim device to perform calculations on weak elliptic curves in order to leak the secret key, it is necessary to carefully select the considered ECC curve: the one adopted in our implementation (see Section IV for details) satisfies this requirement. And in terms of side-channel attacks (at least for what concerns side timing-channels), the ECC hardware implementation adopted in our prototype employs the ▇▇▇▇▇▇▇▇▇▇ ladder [6] algorithm (see Section IV) and thus guarantees that the time needed to perform ECC point multiplication is independent from side-channel information and does not leak secret key information.
Appears in 2 contracts