We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

MachineOS: a Trusted, SecureBoot Image-based Container OS

00:00

Formal Metadata

Title
MachineOS: a Trusted, SecureBoot Image-based Container OS
Title of Series
Number of Parts
542
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Machine OS, designed for appliances used in lights-out/hands-off environments, is an environment for Secure and Trusted booting of an image-based Linux OS leveraging TPM 2.0 security chips to guard unique platform secrets only made available if the chain of trust from the platform, through the kernel and into user-space is verified. The platform secret is used to attest, at runtime, device and software veracity for creating clusters of systems with a common root of trust extended from the platform. The secured (PCR7) initial environment of Machine OS checks a signed (Machine OS CA) manifest of images present. It then verifies (dm-verity) the images before handing over execution control. Machine OS leverages opensource tools for building (project-stacker), signing (notary/cosign) and hosting (project-zot) such images. The design of Machine OS has some similarities with the UAPI proposal for Trusted/SecureBoot, making for an interesting comparison on design goals. Our design is focused around the goal not of preventing alternative boot images, but denying all images which are not verified access to a set of TPM-protected secrets. Furthermore, to support re-use of a single signed UKI by multiple unrelated projects, image manifests are signed by product certificates which are all signed by one company-wide CA, whose certificate is shipped as part of the (protected) UKI.
14
15
43
87
Thumbnail
26:29
146
Thumbnail
18:05
199
207
Thumbnail
22:17
264
278
Thumbnail
30:52
293
Thumbnail
15:53
341
Thumbnail
31:01
354
359
410
IcosahedronVirtual machineComputer-generated imageryComputer animation
Identity managementChainPublic key certificateRevision controlStructural loadEncryptionComputing platformFormal verificationReading (process)Extension (kinesiology)RootChainInformation securityPublic key certificatePoint (geometry)Operating systemData centerPublic-key cryptographyInformation privacyPhysical systemComputing platformNumberInformationMinimal surfaceFocus (optics)Integrated development environmentKey (cryptography)Disk read-and-write headAuthenticationData storage deviceUniqueness quantificationProduct (business)Identity managementComputer hardwareSoftwareRun time (program lifecycle phase)
Sign (mathematics)Lattice (order)Raw image formatComputer animation
Component-based software engineeringRun time (program lifecycle phase)Installation artMaxima and minima
BootingFormal verificationStructural loadRead-only memoryComputer-generated imageryComputer hardwareProcess (computing)DatabaseElectronic signatureSkewness
Process (computing)BootingFirmwareKernel (computing)RootComputer-generated imageryWorkloadProduct (business)Pivot elementPublic key certificateFormal verificationData integrityGEDCOMConfiguration spaceEinheitswurzelContinuous functionAdditionMoore's lawRevision controlRun time (program lifecycle phase)Data storage deviceView (database)WhiteboardPhysical systemMeasurementKey (cryptography)Service (economics)Medical imagingBootingQuicksortFile systemKernel (computing)MathematicsRevision controlProduct (business)Integrated development environmentSynchronizationRun time (program lifecycle phase)Formal verificationAdditionRepository (publishing)Configuration spaceSoftwareElectronic signatureDatabaseCASE <Informatik>Block (periodic table)Reading (process)Matching (graph theory)Read-only memoryMultiplication signLine (geometry)Computer animation
Program flowchart
Transcript: English(auto-generated)
And I'm going to talk to you today about MachineOS.
MachineOS, we've been working on for a couple of years, and its design points are focused on appliances for data centers, so it lights out hands-off environments. And over years ago, we presented at the Linux Security Summit
some details about securing secrets and TPMs for data center advisors with some of the information about how we are going to keep those secrets in these environments. And so the key pieces that we've incorporated from that design discussion from MachineOS
focus on use of security platform and the TPM2 device that we need to guard a unique identity and keys that would be placed into a deep key that would be used for identity and device authenticity.
And further, the operating system will be able to extract the deep key secrets if we have securely moved it all the way up to criminal user's heads and that the chain of trust is still verified. It ensures that we are the device, on the device we expect, and we run it in software we expect as well
before we can access these secrets. We also include support for unintended decrypted storage for access to data protection and incorporating continuous updates. The root of trust for MachineOS is a certificate of an associated key pair
which will be protected in TPM hardware. The certificate holds a product ID and a serial number that binds it to the physical system that we are using. And then, picking the certificate key pair in TPM,
those are inserted at manufacturing time, and then the certificate will give us a mutable identity to verify that the device is authentic and that we'll be running the software that the product expects and that it hasn't been tampered with.
At the runtime of DevOps MachineOS, we start with our advice for keeping Texas from going into
unexpected exchanges.
We loaded and we're executing sort of a normal view of how the kernel comes up. We're transitioning to the loaded-in MFSes startup. And then we get into where the MachineOS trades are running. We're going to unlock decrypted storage
to pull out our EA policies that are loaded into the TPM and we just have to access the registers to make sure that the values in these registers are what we expect. If they're not, then we help the system run off on to the board for something that's been modified for tampered with. And we don't have access to
any of the secrets in the TPM that we've locked away. On success, though, we can go over the trust keys and certs, which pass phrases that are protected in the TPM, loaded into the TPM, and used for only by the user. And then once we have extracted that information,
we extend the XR7 with our own measurement which will protect further access to the TPM from any of the runtime services. Before we start the containers of the runtime service, we brought along that we have to go through steps to ensure that
the images that were included on the system match the product and the product's expectations. And these will have been signed by the product certificates to verify certificates, signatures, and that all lines up well.
So for each of the OCI images in the manifest, those will be mounted and then the services can be started. We also auctioned into a particular OCI which gives us a custom environment. We're perfectly fine
running just out of the area. To the OCIs, we want to ensure that the image and the storage haven't been modeled. And the way we do that is the stacker builds us a squash request for all the layers in the
OCI, which is a read-only file system that is mounted. In addition to the squash request layer, the OCI images have varied matches that were calculated at build time. And with that, we can build a dean-ferrin block device in Linux which, on access as we read the first time we accessed that block device, the kernel will
do the work of hashing and evaluating whether that block is valid or it's been tampered with. In the case that it's been tampered with, then the IO for reading will fail. The tampered will stop. The system can be rebooted. We won't move any further on the system. For more details,
later today, my colleague Scott Moser will be in the Containment Dev Room at 1405 talking more about this in depth. Please go see him later. For our updates, we have continuous updates
as we can sync from our image repository. An update is much like what we do when we boot up. We have to go through the same sort of verification of signatures such that we know that this is the software that's expected for the device that we're running on and that all of the layers that we pulled out have been signed correctly.
Once we've applied that, we can update our configuration database to point to those versions. For currently executing containers, we can restart them, but if we have changes to reboot RFS or UKI, we'll need to reboot the system so that we can execute the new versions.
Lastly, for offline protection or other prevention of maybe there's sort of an excellent challenge or a zero-day run over kernel, we need to talk about verification. And we should not ask those verification