A Fast Hash Family for Memory Integrity

We give a first construction of an ϵ-balanced hash family based on linear transformations of vectors in $\mathbb{F}_2$, where ϵ = 1/(2n − 1) for n-bit hash values, regardless of the message size. The parameter n is also the bit length of the input blocks and the internal state, and can be chosen arbitrarily without design changes, This hash family is fast, easily parallelized, and requires no initial setup. A secure message authentication code can be obtained by combining the hash family with a pseudo random function. These features make the hash family attractive for memory integrity protection, while allowing generic use cases

Size, Speed, and Security: An Ed25519 Case Study

Ed25519 has significant performance benefits compared to ECDSA using Weierstrass curves such as NIST P-256, therefore it is considered a good digital signature algorithm, specially for low performance IoT devices. However, such devices often have very limited resources and thus, implementations for these devices need to be as small and as performant as possible while being secure. In this paper we describe a scenario in which an obvious strategy to aggressively optimize an Ed25519 implementation for code size leads to a small memory footprint that is functionally correct but vulnerable to side-channel attacks. This strategy serves as an example of aggressive optimizations that might be considered by cryptography engineers, developers, and practitioners unfamiliar with the power of Side-Channel Analysis (SCA). As a solution to the flawed implementation example, we use a computer-aided cryptography tool generating formally verified finite field arithmetic to generate two secure Ed25519 implementations fulfilling different size requirements. After benchmarking and comparing these implementations to other widely used implementations our results show that computer-aided cryptography is capable of generating competitive code in terms of security, speed, and size

Trusted Hart for Mobile RISC-V Security

The majority of mobile devices today are based on Arm architecture that supports the hosting of trusted applications in Trusted Execution Environment (TEE). RISC-V is a relatively new open-source instruction set architecture that was engineered to fit many uses. In one potential RISC-V usage scenario, mobile devices could be based on RISC-V hardware. We consider the implications of porting the mobile security stack on top of a RISC-V system on a chip, identify the gaps in the open-source Keystone framework for building custom TEEs, and propose a security architecture that, among other things, supports the GlobalPlatform TEE API specification for trusted applications. In addition to Keystone enclaves the architecture includes a Trusted Hart -- a normal core that runs a trusted operating system and is dedicated for security functions, like control of the device's keystore and the management of secure peripherals. The proposed security architecture for RISC-V platform is verified experimentally using the HiFive Unleashed RISC-V development board.Comment: This is an extended version of a paper that has been published in Proceedings of TrustCom 202

Split keys for station-to-station (STS) protocols

Aim For authentication and key agreement, it is advisable to reduce the risks of key exposure and provide an additional level of control over key usage. This can be achieved by splitting the secret key across several devices, requiring their cooperation to use the key effectively. Methods We have studied the split-key setting in the context of the station-to-station with key derivation function (STS-KDF) protocol – a well-known two-party authenticated key agreement protocol based on the Diffie-Hellman key exchange and digital signatures – and developed it further. We use the methods of design science, modeling, and formal verification. Results First, we have found a new reflection attack against the STS-KDF protocol for scenarios where several entities share the same private key. We designed a modification of that protocol, called STS-KDF with certificate binding (STS-KDF-CB), that includes measures against this attack and enhances user privacy. Second, we designed the STS-KDF-CB with the key encapsulation mechanism (KEM) protocol, where KEM is used instead of the Diffie-Hellman key exchange and digital signatures. Third, we designed split-key variants of the STS-KDF-CB and STS-KDF-CB with KEM protocols. The security properties of the STS-KDF protocol, the STS-KDF-CB protocols, and their split-key variants were formally verified using the ProVerif tool. Conclusion We have increased security and privacy for authentication and key agreement by developing new variants of the STS-KDF protocol. In addition, we have STS-KDF variants for the split key setting. Future work includes implementation of the protocols and extension to the case where one of the split-key devices provides attestation for the other.Peer reviewe