Information flow security of multi-threaded distributed programs

We study noninterference in the setting of multi-threaded distributed programs in which threads share local memories and multi-threaded processes communicate over an insecure network using encryption primitives to secure messages. We extend a simple imperative language with cryptographic operations which are modelled as special expressions respecting the Dolev-Yao assumptions. Then, we adapt to our setting the notion of patterns proposed by Abadi and Rogaway for modelling the equivalence of cryptographic expressions. Based on this notion, we naturally obtain a definition of strongly secure programs corresponding to the one proposed by Sabelfeld and Sands for programs without cryptography. This is, to the best of our knowledge, the first definition of noninterference in a multi-threaded distributed setting, with insecure channels and cryptography. We prove compositionality of secure programs and we adapt the type system of Sabelfeld and Sands to our setting, proving its correctness

Why Is Network Reselection an Issue for Cross-Border Vehicular Applications?

Safety-critical advanced driver-assistance systems (ADAS) are expected to benefit from cellular vehicle-to-everything communication, providing both short-range and long-range wireless connectivity between vehicles and road/network infrastructure equipment. However, upon switching between adjacent coverage areas belonging to different network operators, the wireless connectivity may be discontinued. This issue prevents network service continuity and causes interruption of ADAS service availability. In this paper, we aim at assessing the average duration of service interruption due to such network reselection procedures. We provide performance evaluation results highlighting that there is a wide gap between the best case scenario and the worst case scenario. Moreover, we propose a simple heuristic to limit the downside of the lack of cooperation between network operators; our heuristic algorithm, which does not require a tight integration between the operators, performs much better than the worst case and it is fairly comparable with the best case scenario. Nevertheless the present work highlights the importance of a tighter integration between network operators to reduce the delay to the minimum

Type-based Analysis of Key Management in PKCS#11 cryptographic devices

PKCS#11, is a security API for cryptographic tokens. It is known to be vulner- able to attacks which can directly extract, as cleartext, the value of sensitive keys. In particular, the API does not impose any limitation on the different roles a key can assume, and it permits to perform conflicting operations such as asking the token to wrap a key with another one and then to decrypt it. Fixes proposed in the literature, or implemented in real devices, impose policies restricting key roles and token functionalities. In this paper we define a simple imperative programming language, suitable to code PKCS#11 symmetric key management, and we develop a type-based analysis to prove that the secrecy of sensitive keys is preserved under a certain policy. We formally analyse existing fixes for PKCS#11 and we propose a new one, which is type-checkable and prevents conflicting roles by deriving dif- ferent keys for different roles. We develop a prototype type-checker for a software token emulator written in C and we experiment on various working configurations

Type-Based Analysis of PIN Processing APIs

We examine some known attacks on the PIN verification framework, based on weaknesses of the security API for the tamper-resistant Hardware Security Modules used in the network. We specify this API in an imperative language with cryptographic primitives, and show how its flaws are captured by a notion of robustness that extends the one of Myers, Sabelfeld and Zdancewic to our cryptographic setting. We propose an improved API, give an extended type system for assuring integrity and for preserving confidentiality via randomized and non-randomized encryptions, and show our new API to be type-checkable