Slides from two day course on Vanadium https://vanadium.github.io/
We report the success of a project that Google performed as a proof-of-concept for increasing
confidence in first-instruction integrity across a variety of server and peripheral environments. We
begin by motivating the problem of first-instruction integrity and share the lessons learned from
our proof-of-concept implementation. Our goal in sharing this information is to increase industry
support and engagement for similar designs. Notable features include a vendor-agnostic capability
to interpose on the SPI peripheral bus (from which bootstrap firmware is loaded upon power-on in a
wide variety of devices today) without negatively impacting the efficacy of any existing vendor- or
device-specific integrity mechanisms, thereby providing additional defense-in-depth.
Users often don’t follow expert advice for staying secure online, but the reasons for users’ noncompliance
are only partly understood. More than 200 security experts were asked for the top three pieces of advice
they would give non-tech-savvy users. Te results suggest that, although individual experts give thoughtful,
reasonable answers, the expert community as a whole lacks consensus.
The record layer is the main bridge between TLS applications and internal sub-protocols. Its core functionality is an elaborate form of authenticated encryption: streams of messages for each sub-protocol (handshake, alert, and application data) are fragmented, multiplexed, and encrypted with optional padding to hide their lengths. Conversely, the sub-protocols may provide fresh keys or signal stream termination to the record layer. Compared to prior versions, TLS 1.3 discards obsolete schemes in favor of a common construction for Authenticated Encryption with Associated Data (AEAD), instantiated with algorithms such as AES-GCM and ChaCha20-Poly1305. It differs from TLS 1.2 in its use of padding, associated data and nonces. It also encrypts the content-type used to multiplex between sub-protocols. New protocol features such as early application data (0-RTT and 0.5-RTT) and late handshake messages require additional keys and a more general model of stateful encryption. We build and verify a reference implementation of the TLS record layer and its cryptographic algorithms in F*, a dependently typed language where security and functional guarantees can be specified as pre-and post-conditions. We reduce the high-level security of the record layer to cryptographic assumptions on its ciphers. Each step in the reduction is verified by typing an F* module, for each step that involves a cryptographic assumption, this module precisely captures the corresponding game. We first verify the functional correctness and injectivity properties of our implementations of one-time MAC algorithms (Poly1305 and GHASH) and provide a generic proof of their security given these two properties. We show the security of a generic AEAD construction built from any secure one-time MAC and PRF. We extend AEAD, first to stream encryption, then to length-hiding, multiplexed encryption. Finally, we build a security model of the record layer against an adversary that controls the TLS sub-protocols. We compute concrete security bounds for the AES_128_GCM, AES_256_GCM, and CHACHA20_POLY1305 ciphersuites, and derive recommended limits on sent data before re-keying. We plug our implementation of the record layer into the miTLS library, confirm that they interoperate with Chrome and Firefox, and report initial performance results. Combining our functional correctness, security, and experimental results, we conclude that the new TLS record layer (as described in RFCs and cryptographic standards) is provably secure, and we provide its first verified implementation.
Production systems at Google consist of a constellation of microservices1 that collectively issue O(1010) Remote Procedure Calls (RPCs) per second. When a Google engineer schedules a production workload2, any RPCs issued or received by that workload are protected with ALTS by default. This automatic, zero-configuration protection is provided by Google’s Application Layer Transport Security (ALTS). In addition to the automatic protections conferred on RPC’s, ALTS also facilitates easy service replication, load balancing, and rescheduling across production machines. This paper describes ALTS and explores its deployment over Google’s production infrastructure.
“Retpoline” sequences are a software construct which allow indirect branches to be isolated from speculative execution. This may be applied to protect sensitive binaries (such as operating system or hypervisor implementations) from branch target injection attacks against their indirect branches.
The name “retpoline” is a portmanteau of “return” and “trampoline.” It is a trampoline construct constructed using return operations which also figuratively ensures that any associated speculative execution will “bounce” endlessly.
(If it brings you any amusement: imagine speculative execution as an overly energetic 7-year old that we must now build a warehouse of trampolines around.)
Abstract. Access control is central to security in computer systems. Over the
years, there have been many efforts to explain and to improve access control,
sometimes with logical ideas and tools. This paper is a partial survey and discussion
of the role of logic in access control. It considers logical foundations
for access control and their applications, in particular in languages for security
policies. It focuses on some specific logics and their properties. It is intended
as a written counterpart to a tutorial given at the 2009 International School on
Foundations of Security Analysis and Design.