OpenSSH: 8.2 Release Notes

This release adds support for FIDO/U2F hardware authenticators to
OpenSSH. U2F/FIDO are open standards for inexpensive two-factor
authentication hardware that are widely used for website
authentication. In OpenSSH FIDO devices are supported by new public
key types “ecdsa-sk” and “ed25519-sk”, along with corresponding
certificate types.

FIDO/U2F OpenSSH keys consist of two parts: a “key handle” part stored
in the private key file on disk, and a per-device private key that is
unique to each FIDO/U2F token and that cannot be exported from the
token hardware. These are combined by the hardware at authentication
time to derive the real key that is used to sign authentication
challenges.

For tokens that are required to move between computers, it can be
cumbersome to have to move the private key file first. To avoid this
requirement, tokens implementing the newer FIDO2 standard support
“resident keys”, where it is possible to effectively retrieve the key
handle part of the key from the hardware.

Source: https://www.openssh.com/releasenotes.html#8.2

The Linux Kernel Now Seeing Patches For AMD SEV-ES “Encrypted State” Support – Phoronix

AMD SEV-ES allows for protecting the guest register state from the hypervisor. CPU register state is encrypted that cannot be accessed or modified by the system hypervisor. The intent of SEV-ES is to help fend off control-flow attacks by modifying the VM state, unauthorized reading of the virtual machine state, and other similar attacks. SEV-ES does allow for selectively sharing certain information to the hypervisor about certain switches where needed.

Source: https://www.phoronix.com/scan.php?page=news_item&px=AMD-SEV-ES-Linux-2020-Patches

[RFC PATCH] mm: extend memfd with ability to create “secret” memory areas – Mike Rapoport

Extend memfd_create() system call with the ability to create memory areas
visible only in the context of the owning process and not mapped not only
to other processes but in the kernel page tables as well.

The user will create a file descriptor using the memfd_create system call.
The user than has to use ioctl() to define the desired protection mode for
the memory associated with that file descriptor and only when the mode is
set it is possible to mmap() the memory. For instance, the following
exapmple will create an uncached mapping (error handling is omitted):

Source: https://lore.kernel.org/lkml/20200130162340.GA14232@rapoport-lnx/

Keeping secrets in memfd areas [LWN.net]

The memfd subsystem wasn’t designed for address-space isolation; indeed, its initial purpose was as a sort of interprocess communication mechanism. It does, however, provide a way to create a memory region attached to a file descriptor with specific characteristics; a memfd can be “sealed”, for example, so that a recipient knows that it will not be changed. Rapoport decided that it would be a good foundation on which to build a “secret memory” feature.

Source: https://lwn.net/SubscriberLink/812325/b642e849751b9068/

The Update Framework Specification

Software is commonly updated through software update systems. These systems can be package managers that are responsible for all of the software that is installed on a system, application updaters that are only responsible for individual installed applications, or software library managers that install software that adds functionality such as plugins or programming language libraries.

Software update systems all have the common behavior of downloading files that identify whether updates exist and, when updates do exist, downloading the files that are required for the update. For the implementations concerned with security, various integrity and authenticity checks are performed on downloaded files.

We need to provide a framework (a set of libraries, file formats, and utilities) that can be used to secure new and existing software update systems.

The framework should enable applications to be secure from all known attacks on the software update process. It is not concerned with exposing information about what software is being updated (and thus what software the client may be running) or the contents of updates.

The framework should provide means to minimize the impact of key compromise. To do so, it must support roles with multiple keys and threshold/quorum trust (with the exception of minimally trusted roles designed to use a single key). The compromise of roles using highly vulnerable keys should have minimal impact. Therefore, online keys (keys which are used in an automated fashion) must not be used for any role that clients ultimately trust for files they may install.

The framework must be flexible enough to meet the needs of a wide variety of software update systems.

Source: https://github.com/theupdateframework/specification/blob/master/tuf-spec.md#the-update-framework-specification

in-toto: Providing farm-to-table guarantees for bits and bytes | USENIX

The software development process is quite complex and involves a number of independent actors. Developers check source code into a version control system, the code is compiled into software at a build farm, and CI/CD systems run multiple tests to ensure the software’s quality among a myriad of other operations. Finally, the software is packaged for distribution into a delivered product, to be consumed by end users. An attacker that is able to compromise any single step in the process can maliciously modify the software and harm any of the software’s users.

To address these issues, we designed in-toto, a framework that cryptographically ensures the integrity of the software supply chain. in-toto grants the end user the ability to verify the software’s supply chain from the project’s inception to its deployment. We demonstrate in-toto’s effectiveness on 30 software supply chain compromises that affected hundreds of million of users and showcase in-toto’s usage over cloud-native, hybrid-cloud and cloud-agnostic applications. in-toto is integrated into products and open source projects that are used by millions of people daily.

Source: https://www.usenix.org/conference/usenixsecurity19/presentation/torres-arias

Towards a Timely Causality Analysis for Enterprise Security

Abstract—The increasingly sophisticated Advanced Persistent
Threat (APT) attacks have become a serious challenge for enterprise IT security. Attack causality analysis, which tracks multi-hop
causal relationships between files and processes to diagnose attack
provenances and consequences, is the first step towards understanding APT attacks and taking appropriate responses. Since
attack causality analysis is a time-critical mission, it is essential
to design causality tracking systems that extract useful attack
information in a timely manner. However, prior work is limited
in serving this need. Existing approaches have largely focused on
pruning causal dependencies totally irrelevant to the attack, but
fail to differentiate and prioritize abnormal events from numerous
relevant, yet benign and complicated system operations, resulting
in long investigation time and slow responses.
To address this problem, we propose PRIOTRACKER, a backward and forward causality tracker that automatically prioritizes
the investigation of abnormal causal dependencies in the tracking
process. Specifically, to assess the priority of a system event, we
consider its rareness and topological features in the causality
graph. To distinguish unusual operations from normal system
events, we quantify the rareness of each event by developing
a reference model which records common routine activities in
corporate computer systems. We implement PRIOTRACKER, in
20K lines of Java code, and a reference model builder in 10K lines
of Java code. We evaluate our tool by deploying both systems in
a real enterprise IT environment, where we collect 1TB of 2.5
billion OS events from 150 machines in one week. Experimental
results show that PRIOTRACKER can capture attack traces that
are missed by existing trackers and reduce the analysis time by
up to two orders of magnitude.

Source: https://www.princeton.edu/~pmittal/publications/priotracker-ndss18