The TPM2 software community
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 561 | |
| 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 | 10.5446/44598 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
SoftwareIntelArchitectureBootingPrototypeLattice (order)Formal verificationPhysical systemMiniDiscCryptographyEncryptionServer (computing)Directed setAbstractionFunction (mathematics)Integrated development environmentFlow separationComputer programmingDefault (computer science)Expert systemConfiguration spaceRead-only memoryResource allocationAerodynamicsFlash memorySoftwareModule (mathematics)FrequencyDemonCartesian coordinate systemComputing platformFirmwareIntegrated development environmentDigital rights managementThread (computing)SpacetimeDifferent (Kate Ryan album)BootingQuicksortOpen sourceLevel (video gaming)ImplementationPoint cloudStandard deviationIterationMereologyRight angleCASE <Informatik>ComputerProjective planeDataflowInformation securityBitComputer program1 (number)MotherboardState of matterStack (abstract data type)CoprocessorInformationMaxima and minimaUniform boundedness principleLibrary (computing)Default (computer science)Endliche ModelltheorieComputer virusDebuggerCryptographyPrototypeComputer animation
05:38
Interface (computing)Data transmissionService-oriented architectureData storage deviceAbstractionCryptographyDevice driverPhysical systemMechanism designDependent and independent variablesAerodynamicsInterprozesskommunikationAutomationContext awarenessResource allocationRead-only memoryImplementationPersonal digital assistantFrame problemBootingFirmwareAuthenticationComputer networkConnectivity (graph theory)PrototypeSoftware testingCommunications protocolQuery languageData bufferKey (cryptography)Partition (number theory)EncryptionRevision controlFunction (mathematics)Functional (mathematics)Link (knot theory)Serial portLine (geometry)Device driverMeasurementBijectionFirmwareBootingPhysical systemCommunications protocolComputing platformProjective planeRevision controlBuffer solutionComputerMultiplication signCrash (computing)Slide ruleSemiconductor memoryKey (cryptography)Symbol tableSpacetimeReading (process)Resource allocationCryptographyAdditionWindowBuildingData miningAlgorithmConfiguration spaceNon-volatile memoryOperator (mathematics)Gastropod shellCodeSoftwareImplementationDigital rights managementLevel (video gaming)Interface (computing)DiagramLibrary (computing)CASE <Informatik>Data transmissionPartition (number theory)CuboidEncryptionComputer architectureInternet service providerCartesian coordinate systemCategory of beingWritingService-oriented architectureRight angleParameter (computer programming)TouchscreenWeb pageOrder (biology)Kernel (computing)Software testingMoving averageBitCore dumpAbstractionComputer animation
11:10
Convex hullInclusion mapPhysical systemFormal verificationCommon Language InfrastructureLibrary (computing)Information securityPasswordAuthenticationCellular automatonProjective planeCore dumpOpcodeSoftwareSymbol tableFunctional (mathematics)Function (mathematics)Computer simulationAutomationSoftware testingComputer clusterComputerLaptopAuthenticationPasswordIterationCryptographyKey (cryptography)Execution unitInformation securityCASE <Informatik>MiniDiscVirtual machineType theoryInteractive televisionBootingState of matterRemote procedure callConnected spaceSource codeComputer animation
13:11
MereologyOperator (mathematics)Kernel (computing)CASE <Informatik>LaptopToken ringAuthorizationConfiguration spaceCartesian coordinate systemBootingNumberFreewareWordComputing platformSharewareCalculationComputer animation
14:38
Physical systemFormal verificationCommon Language InfrastructureLibrary (computing)Information securityPasswordAuthenticationCellular automatonMiniDiscCryptographyPersonal identification numberData dictionary5 (number)CryptographyOperator (mathematics)Data miningSoftware testingImplementationSoftwareLibrary (computing)Interface (computing)Projective planePasswordCASE <Informatik>MiniDiscHoaxPartition (number theory)Subject indexingInformation securityKey (cryptography)Regular graphBootingLevel (video gaming)DigitizingLoginRippingData dictionaryEmailComputer hardwareEndliche ModelltheorieWindowMultiplication signModule (mathematics)Client (computing)Boundary value problemForcing (mathematics)Arithmetic meanEncryptionType theoryPhysical systemRootPersonal identification numberMinimal surfaceComputer animation
17:37
MiniDiscRing (mathematics)Data typeBranch (computer science)File systemRootSoftware testingMessage passingOrder (biology)Parameter (computer programming)Type theoryTrailSharewarePhysical systemMiniDiscOpen setComputer animation
18:27
Software frameworkEncryptionPlug-in (computing)ImplementationVolumeMiniDiscPeer-to-peerServer (computing)Module (mathematics)Point (geometry)SoftwareServer (computing)Open setPersonal identification numberPlug-in (computing)Endliche ModelltheorieEncryptionCryptographyWeb pagePhysical systemMiniDiscConfiguration spaceKey (cryptography)Link (knot theory)Greatest elementCartesian coordinate systemBootingLatent heatProjective planePlastikkarteBitSoftware developerComputer hardwareInformation securityComputer fileImplementationGoodness of fitIntegrated development environmentClient (computing)Web 2.0Computer animation
21:36
InfinityInformationDefault (computer science)Field (computer science)CodePublic key certificateTablet computerPrinciple of localityGUI widgetInternetworkingSelf-organizationSheaf (mathematics)Execution unitServer (computing)Address spaceEmailState of matterParameter (computer programming)Form (programming)Key (cryptography)Set (mathematics)System callWeb 2.0CodeComputer fileServer (computing)CASE <Informatik>Parameter (computer programming)Default (computer science)Public key certificateoutputSharewareSoftware testingComputer animation
22:33
Peg solitaireRSA (algorithm)Continuum hypothesisAdvanced Encryption StandardServer (computing)Binary fileAreaInformationDefault (computer science)Field (computer science)CodeState of matterPrinciple of localityGUI widgetInternetworkingSelf-organizationSheaf (mathematics)Execution unitAddress spaceEmailParameter (computer programming)Public key certificateClient (computing)Virtuelles privates NetzwerkOpen setAuthenticationAlgorithmImplementationToken ringCryptographySharewareSoftware maintenanceInformation securityMechanism designComputer hardwareTexture mappingMetadataOperations researchTask (computing)CloningIntelElectronic signatureSign (mathematics)Context awarenessHierarchyHash functionFile formatComputer fileFormal verificationFormal languageGoogolKeyboard shortcutSoftwareWrapper (data mining)Public key certificateAlgorithmStandard deviationWeb pageResultantOpen setSubsetConnected spaceInjektivitätPublic-key cryptographyUniversal product codePlastikkarteGateway (telecommunications)Formal languageMultiplication signComputer hardwareSign (mathematics)Electronic signatureType theorySharewareVirtuelles privates NetzwerkObject-oriented programmingSuite (music)MereologyOrder (biology)Gastropod shellObject modelMappingDrop (liquid)1 (number)Web browserPersonal identification numberLatent heatSoftwarePatch (Unix)CodePhysical systemCommunications protocolCryptographyEncryptionKey (cryptography)Uniform resource locatorModule (mathematics)Slide ruleMiniDiscVirtual machineComputerServer (computing)Default (computer science)CASE <Informatik>Computer architectureObject (grammar)Projective planeMathematicsMechanism designLoginImplementationAuthenticationBitParameter (computer programming)DatabaseWrapper (data mining)Computer fileInterface (computing)Structural loadClient (computing)Token ringSet (mathematics)Operator (mathematics)Scripting languageKeyboard shortcutAverageHypothesisIntegrated development environmentEndliche ModelltheorieContext awarenessFacebookMetadataLibrary (computing)Cartesian coordinate systemComputing platformComputer animation
31:20
InformationData typeData structureRepresentation (politics)Order (biology)Point (geometry)Functional (mathematics)Context awarenessLatent heatComputer animation
32:12
Keyboard shortcutAuthorizationParameter (computer programming)Sign (mathematics)Type theoryData structureMereologyKey (cryptography)CurveEncryptionOperator (mathematics)Set (mathematics)CASE <Informatik>National Institute of Standards and TechnologySource code
33:05
Computer networkBuffer solutionPatch (Unix)Network topologyElectric currentSimulationDependent and independent variablesStreaming mediaParsingDisintegrationLatin squareEmailElectronic visual displayHill differential equationMIDIInfinitySine10 (number)Integrated development environmentFlow separationProcess (computing)Similarity (geometry)Smart cardComputer hardwareBefehlsprozessorKolmogorov complexityPrototypeLibrary (computing)Service-oriented architectureBoundary value problemBuildingSoftware testingPublic domainAssociative propertyInformation securityVector potentialExploit (computer security)ArmTime zoneMechanism designLibrary (computing)SoftwareOperator (mathematics)Flow separationEmailComplex (psychology)InformationBoundary value problemProcess (computing)BefehlsprozessorLink (knot theory)DienstprogrammAssociative propertyCASE <Informatik>Digital rights managementCuboidInteractive televisionNumberStructural loadComputer simulationDependent and independent variablesBranch (computer science)CodeField (computer science)Integrated development environmentAreaSoftware developerParsingEndliche ModelltheorieFlagProgrammschleifeWindowSocket-SchnittstelleData structureGraphics tabletOnline help1 (number)Motion captureProfil (magazine)Goodness of fitReal numberProjective planeComputer architectureDebuggerBuffer solutionMultiplication signStack (abstract data type)Communications protocolError messageBitPrototypeIntegerResultantTelecommunicationTopological vector spaceAuthorizationForceConnected spaceTerm (mathematics)Physical systemKernel (computing)Operating systemOrder (biology)Computer fileUsabilityData flow diagramSpacetimeBuildingComputer animation
40:39
SoftwareLattice (order)Integrated development environmentSoftwareWeb pageImplementationProjective planeMinimal surfaceDigital rights managementContext awarenessSpacetimeStandard deviationPoint (geometry)Kernel (computing)Patch (Unix)Mechanism designDirection (geometry)DienstprogrammLibrary (computing)Product (business)Server (computing)Block (periodic table)Interface (computing)Information securityDivisorMultiplication signMessage passingOpen sourcePhysical systemFingerprintRepository (publishing)Key (cryptography)Address spaceEmailStress (mechanics)Moment (mathematics)Line (geometry)MiniDiscModal logicDemonProxy serverBuildingCodeMereologyElectronic mailing listComputer simulationVideo gameFunctional (mathematics)Software testingReal numberCartesian coordinate systemLink (knot theory)Bus (computing)Goodness of fitVector potentialComputer animation
48:13
Computer animation
Transcript: English(auto-generated)
00:08
OK, we're going to start the next session. If everyone can take a seat, please stay out of the aisles. And if we can just ask at the end,
00:21
if everyone could just stay in their seats until we finish the Q&A period. I know it can be tough to get wherever you're going, but it's really super disruptive if no one can hear the questions and if these guys can answer. OK, so Philip and Andreas will talk about TPM.
00:42
Hello. Excellent. So thanks, everyone, for showing up. I know we're getting kind of late and we're standing between you and the pub, so we appreciate your attention. We're here today talking, myself, my co-conspirator, Andreas, about some of the work that we've been doing to both standardize the APIs for interfacing with the trust the platform module
01:01
and also to drive adoption in the open source community through an open source implementation of that software stack. So just out of curiosity, just a show of hands from the audience, if you're willing, does everyone here know what the trusted platform module or the TPM is? Lovely. Good, because we're not gonna be doing
01:21
a whole lot of background information in this talk. We're mostly gonna be focusing on our outreach from the open source community that's formed around our implementation and the things we're doing to drive adoption in downstream projects that can benefit from using this cryptographic coprocessor. So the agenda for today is actually pretty simple.
01:40
The first bullet is something we're gonna go through really quick. Little bit of background on the actual software stack and the APIs, but very little. So if you're interested in this stuff, we've been speaking at conferences of the last year and we had a couple talks at the Linux Security Summit in North America as well as some of our friends from Infineon were presenting at the European Linux Security Summit.
02:02
So we highly recommend if you wanna see all the background information about the trials and tribulations that we went through in standardizing and implementing the APIs and the software stack, go check out those talks, please. The rest of it is actually gonna be very straightforward. We'll give you a little bit of an overview of where we're focusing our efforts for the adoption,
02:21
how these projects can benefit from the work, and the state of the actual implementation and our efforts to push these things upstream. And the flow of the talk is gonna be very much like the way that your computer boots. We'll start with the earliest parts of the software that'll be using this stuff and we'll get all the way up
02:40
to a full user space and even some of the prototyping and debugging tools that we're building for folks that are looking to use this and adopt it. So the kind of one of the cornerstones of the design for the TPM software stack, the second iteration for the new TPM2 devices
03:00
is that it is driven by use cases. Everyone who's involved with the standardization and the implementation has a very specific idea for what they wanna use this thing for and it's not always the same. Oftentimes, you'll have people that are more focused on cloud use cases or myself, I work for Intel, we're very interested in firmware and so we go all the way from
03:23
this very low level implementation all the way into much higher level APIs. And so we always have these use cases that are driving the definition and the implementation and so to make all these things work together and to make it so that it answers everybody's needs,
03:41
we have this kind of layered approach. One of the particularly useful things that we've done in the second iteration of the software stack is fix a lot of the problems that made using the first iteration very difficult. That second bullet there, the separating the transport layer from the APIs is very important. I don't know if anyone here has ever programmed with the TPM 1.2 software stack trousers.
04:02
It was a very, very tight coupling between the user space daemon that was a resource management and the actual applications that were using it. So if you ever tried to do something in early boot, like in your initramfs, it was extremely difficult to decouple those things or you had to launch the daemon yourself and then deal with the penalty of that.
04:21
And since it's on the boot path, that's kind of ugly. So by separating the transport layer, we can use these higher level APIs or rather we can take the programming APIs and we can make them usable in all sorts of different environments from firmware all the way up. So that's a particularly good feature of the design and it's something that you'll see
04:42
spoken about a lot in this talk. So we support both synchronous and asynchronous. Obviously, if you wanna have a UI that's sitting in front of your application, you want it to be lively and you don't wanna have to implement your own threading model therein. We expose details if they're needed. So for really embedded use cases, you can get access to very low layers
05:00
of the software stack. But not everyone wants to deal with that complexity and so we try to pick same defaults and we try to actually defer to the downstream distro so that they can choose the right defaults for their platform in the appropriate cases. So the upper layers as we get up this, we're starting to provide more features.
05:21
You know, a constrained environment like firmware, you probably don't wanna have a whole bunch of, crypto libraries built into this thing. You really just want the bare minimum because your goal is really to keep your software small. Flash chip on your motherboard is expensive. Bigger ones are even more expensive. But in the upper layers, we want all these nice things and so we can add the layers,
05:42
rather the additional crypto libraries to enable nice features so that users don't have to implement everything themselves. The TPM2 has this nice transport protection that will provide HMAC and encryption for certain parameters and commands. And so you don't wanna have to implement this all yourself and so we have a higher level API where all that's wrapped up and we do it with OpenSSL or Gcrypt.
06:04
So this is generally how it looks kind of in a box diagram here. The lowest level is gonna be your device driver and above that is gonna be some kind of access broker and resource manager. The TPM itself is very, very small, has very constrained memory. You can only load a few keys into it at a time and so they kind of punt to either user space
06:24
or the kernel to do the resource management for them. On top of that, we have that kind of layer with what we call the TPM command transmission interface. This is that layer for transport abstraction. And on top of that, we have two APIs that we have implemented. The system API, which is a one-to-one correspondence with actual TPM commands, does no crypto operations,
06:43
does no allocations, very strict C99 and very easy to build into embedded applications and we'll talk about that in I think the next slide. The enhanced system API was actually added last year. Thank you to Andreas for that. And this is where we get all those nice features for user space applications.
07:01
Does the crypto for you, does a lot of the hard, repetitive things that you don't wanna have to do in every user space application. The feature API is something we're actually working on right now, we don't have an implementation because the spec isn't yet done, but we're grinding that down and we're hoping to have that done in short order. No guarantees on timing though.
07:22
Okay, so like I was saying, everything is gonna be framed in the way that your computer typically boots up. I'll start by talking about some of the firmware and bootloader use cases. We'll start, Andreas will take up some of the early boot and init RimeFS stuff and then we'll kind of switch back and forth as we talk about the user space and kind of more feature-rich experience there.
07:43
Right, so boot and firmware, UEFI. I work for Intel, UEFI is the firmware architecture that drives Intel platforms. And so being able to use the TPM from UEFI is particularly important to us. The support for the TPM that's in UEFI natively in this what's called the TCG protocol, I think it is,
08:04
it only supports the features that the firmware itself needs. So basically this boils down to configuring platform configuration registers and the algorithms used therein and hash and extend function for extending PCR measurements.
08:20
Then they have one extra command that is just send command and that sends a buffer that is, you know, a TPM command straight to the TPM. Not a particularly friendly interface if you're trying to write some kind of EFI executables that are doing platform provisioning or something like that where you actually need to execute some commands where you may be creating keys or doing crypto operations.
08:41
So, and also bootloaders, things like grub. If you want to have an encrypted boot partition and you wanna use the TPM for protecting your crypto keys, you don't wanna interface directly with the TCG protocol. You wanna talk through the TSS. And so we have this, the TCTI layer where we have this thin, thin layer of software.
09:04
It's maybe 100 lines of code that just sits on top of that send command interface through the native UEFI driver. And we do all the buffer serialization and send commands through that way. We've got the software linked to the project right there up on GitHub.
09:21
And this has actually been a bit of a pet project of mine. I've been going through and implementing all of the CI layers for building and testing this stuff and testing UEFI executables in Travis CI, not exactly the easiest thing to do. So we've done a lot of work to actually, and a lot of respect to the folks from QEMU, OVMF,
09:41
Stefan Berger and his work on the software TPM layer that we're using in the actual test harness. Let me jump to the next one. So when we're actually running one of these things, this is what you'll see coming out in your QEMU window when you're actually running one of these.
10:01
Now unfortunately it truncates the top of it because there's no pager in UEFI. The firmware has a shell and doesn't have a very robust paging interface. So you can take a look here on the screen. You'll see one of the specific properties that I've called out. This is a command from the get capability command where the TPM just tells you a little bit about what it is.
10:21
And that one right there specifically is telling you that the NV buffer or the non-volatile storage buffer, the largest thing you can send to it is 1K at a time. So the largest read or write that you can do to non-volatile memory in one read is 1K. A note there, the GNU EFI versions, I'm using GNU EFI to build this. I haven't integrated it directly into the TNO core build.
10:43
But there's some really, you know, the EFI is all statically linked and making sure that you get all of the symbols is very important when you're doing that. And so I've run into some problems with GNU EFI and missing a few kind of small functions that are usually compiler built-ins. But in 308, if you're trying to reproduce this,
11:02
that's where you're gonna get your best success. So in the previous version, you can roll to the next slide. You'll see what a crash looks like. This is what you get to see when you try to execute a function and you don't actually have that symbol built in your executable. It just tells you invalid opcode and you get a big dump.
11:20
And debugging this is kind of a pain. So what we're doing is we're just building up more infrastructure, just like we do for the rest of the project. Travis CI, automated tasks. We can actually run QEMU, the software simulator. We can launch EFI executables and get output, just like when you run a make check. It's actually pretty convenient. Yeah, and so once we are leaving UEFI
11:43
and BIOS and early boot, the first thing we're heading into is in it already. And usually the first thing that you do, I don't know if you're security interested, is you type in your passwords. That's the first user interaction. Either to decrypt your disk or to log in or to do remote connection or whatnot. And one of the issues that you have there
12:01
is you don't know whether you're actually talking, I don't know, to your own machine. Somebody might have exchanged your machine. Or maybe the more likely case is the infamous evil maid attack, which is where somebody comes into your hotel room, the evil maid, and would switch out, I don't know, the unit RD or even BIOS
12:20
and replace it with something that logs your crypto keys, your passwords to unlock the crypto keys. And on the next iteration of boot, well, they'll steal your laptop and then they are able to recover the passwords and decrypt your disk and whatnot. So that's nothing new, nothing too new.
12:41
And apparently Matthew Garrett found that or found an idea, found a solution for that, which he talked about I think three years ago at the Chaos Communication Congress and he introduced this TPM, T-O-T-P, which stands for the time-based one-time passwords, where basically you would have your computer using the TPM authenticate to you using your cellphone
13:04
that it is still in a valid state. And what this basically would look like, we will see right now. So this is the interactive part of the session. And if you're quick enough, hold on, yeah. Okay, so this is the command I'm running
13:20
and of course this was supposed to happen because it's a live demo. If you're quick enough to scan off this barcode, what it would do is it will register a OTP token with your either Google Authenticator or in my case, the free OTP application, whatever.
13:40
And once you do that, your PC, your laptop and your phone are coupled. And during the next boot, something like a calculator operation would be called during early boot. And it would spit out something like that. And I can compare this number that was spit out there to the number that is on my phone.
14:01
And I don't know if you wanna run it as well. This is the interactive part. It actually fits. So what this does is your laptop is able to prove to you that the early boot, initrd, kernel and BIOS were unaltered while you were away having a few drinks at night. And to see that it actually does work,
14:21
we can, for example, extend the PCR, which is the platform configuration registers of the TPM and again, attempt to calculate the TOTP and we will see we have an authorization failure of the TPM. So TPM will really not do that. Yeah, so as I said, well, I did a re-implementation
14:41
because the software stack, the TPM itself changed drastically between Matthew's implementation and mine. And so I did a few reworks, pushed the key actually into the TPM for the crypto operation, which 1.2 didn't support so he couldn't support any of his software and also split up the whole project into a library
15:00
for reuse and a command line tool. And you should go check it out, test it, maybe send a pull request for a Plymouth interface to that and whatnot. The next thing we're doing when we're still in early boot is usually we wanna decrypt our boot partition, our root partition, not the boot partition.
15:20
That's where we got the initrd from but the actual root partition. And well, why would you wanna use the TPM for that? Well, first of all, it's the primary use case for TPMs for a long time, at least in general, I think, which is the BitLocker system by Microsoft for Windows which does full disk encryption using the hardware security module.
15:40
And why would you actually wanna use that? Well, the first thing is it provides you with hardware-based dictionary attack protection. So if you really wanna be certain that your disk, if it's mirrored today, cannot be decrypted with somebody running brute force attacks for five years, you don't have any means for that
16:01
except for very, very long passwords which I personally cannot stand. And so wouldn't it be nice to just have like a pin for your login, like a three, four, five, six digit pin, whatever your security level is. That's actually possible if you use a hardware security module that would protect stuff for you. The other thing is that
16:21
this is a more philosophical thing. If you have your key encryption keys be derived from your password and you change your password, all you're doing is, philosophically speaking, just adding a password. Because if somebody copied your Lux header beforehand and then you change your password and he copies the same one again,
16:41
well, they have two targets for the brute force attacks. Whereas, so there's no actual invalidation of the old password. It's only always adding a new password given an attacker model where we assume that the attacker can always copy the Lux headers. If you have a hardware security module, you can actually change the password because the old password will be invalid.
17:02
And this is, well, this is what the Lux headers look like. So here we see like the original Lux header where we have the regular key type Lux2. And here's the new implementation where we have the type TPM2. Where we say it's, well, it's in this NV index and the TPM, there's no DA protection
17:21
or there is DA protection and it can even be bound to PCRs, similarly to the TPM TOTP thing. It's still in the PR because we're still figuring out where to put the feature. Is it in the client application? Is it in the library? So that still needs to be discussed. But we have a demo.
17:41
Ain't that great? So as you see here, the only thing I'm changing is I'm setting the type to Lux2. Let me increase that in size. And I'm adding the minus, the dash dash TPM parameter. And this is all you have to do in order to enable that feature. It works seamless.
18:01
And yeah, now we formatted it. If we wanna open it, I'm opening now with test pass because, test pass phrase because I don't have root access to the device mapper. It seamlessly, without adding any parameters, opened the file system again. So it will integrate with systemd, with dracoot,
18:21
with initrd, with loan disks, you name it. And that's what it's supposed to be like. Similar to using Crip setup alone. And one of the things that we're particularly happy about with the software community we've been trying to build up
18:40
is that we've gotten some really good participation from other parties. You know, the project started a while ago and we've been kind of picking up new people as we go along. And Red Hat has been a really good partner to us in this. We've been working with this guy Javier who's actually did a talk not too long ago, I think it was just last weekend at a Red Hat conference.
19:00
We got a link there, devconf. If you're interested in Clevis, Clevis is a Red Hat tool that does automated decryption of various things. It's not specific to disks, but it can be used and applied to that. And Javier did a bunch of work to use some of our command line tools as a plugin to Clevis for using the TPM to unlock disks.
19:23
Clevis is something I'm not particularly familiar with and I'm not gonna try to pretend to know too much about it. I know generally what it is and what it does and I had to go to the Wikipedia page there to figure out what a Clevis is in the first place. They have this model for plugins that they call pins which I find particularly difficult to get my head around because we deal with a lot of pins when people are typing in kind of passphrases.
19:43
So it's not a pin like you would think for like a smart card, but it's a pin as in the pin that goes through a Clevis fastener, which I found a bit difficult to wrestle with. But one of the interesting things from Javier's talk that was a big takeaway for me as someone who was trying to build this project up was that the quote down at the bottom that Red Hat development efforts are based on
20:02
these TCG specifications and our implementation of it. So we're very grateful to Red Hat and the other folks in the community that have showed up and done interesting work like this. Okay, so now we're leaving early boot in it already and we're actually in the main system. And one of the things that you might be running there is something that uses OpenSSL like a web server,
20:24
an MQTT server, and I don't know what you name it, or a client for that matter. And of course one of the easiest big impact points is to provide an engine for OpenSSL. So the idea how that works is that OpenSSL provides this plugin API where you can define
20:43
your own engine that can be developed independently from the upstream project and that enables, for example, the use of hardware security modules or crypto accelerators or PKC is 11 and I don't know, there's like a bunch of engines out there. And so the most obvious thing was to come up
21:00
and implement an OpenSSL engine to use the TPM with via the TCG specified software stack that is. And so you can find it right there on the GitHub page in the TPM2 software community. And depending on the actual application you're trying to enable TPM usage with,
21:22
it can be as easy as setting this environment variable to a config file where you define the engine and then all of a sudden it starts using TPM keys in the background and you don't have to do anything else. And just to show you how easy it is to actually set up that stuff, again we have a little demo.
21:41
So all we're doing here is we're creating a ECDSA key. We store it in the file mykey. Next thing we do is we generate an X.509 certificate and compared to the regular call that you would do, the only parameters we're adding is actually engine,
22:02
TPM2 TSS and key form engine which defines that the input key is supposed to be parsed by the TPM2 TSS engine. Or we can set country codes if you like or I'll go just for the default in this case. And next thing we do is we just start
22:22
the internal web server of OpenSSL for testing purposes. And again the only thing we're setting is key form engine and engine TPM2 TSS. And we go ahead and we'll use Firefox. Of course we get a warning because we have a self signed certificate here so,
22:42
yeah, have to accept that. And there we go, that's the result of OpenSSL giving you its standard debug page with all the crypto algorithms that are supported. And up here we see that we had a connection acceptance from Firefox.
23:04
So there's kind of a common theme through all these things. The TPM is only useful for various cryptographic operations, either encryption or signing. And so authentication is one of those and we do a lot of authentication when we're connecting over VPNs. So a big part of the adoption that we've seen
23:20
that's very encouraging is that some of the existing upstream or downstream projects, both StrongSwan and OpenConnect have started picking this up and using it either directly through the TSS APIs like StrongSwan does or like OpenConnect using the OpenSSL engine that Andreas was just talking about.
23:41
So StrongSwan has actually been using the TPM for a long time. They implemented a lot of the protocols from the trusted network connect specifications from the 1.2 implementation. I think they're probably one of the only ones that I've seen doing that. Where OpenConnect is a little less esoteric in that it's a drop in replacement for the Cisco client VPN.
24:01
And so it's not a full VPN suite like StrongSwan is with both client and server. It's strictly client and it's used to connect to the Cisco SSL VPNs. Again, authentication is really in these contexts, just the signing operation.
24:20
And so there have been APIs for doing these types of things and interfacing with hardware crypto accelerators for a long time. PKCS 11 has been around longer than I've been in the business. And it's really a gateway for us to just support in existing implementations, existing software projects.
24:44
And we can, just by providing a PKCS 11 compatible interface, we can get basically free support for all these things with no code changes in those projects explicitly. And so this is actually a very new implementation from Bill Roberts at Intel. There's a lot of work that went into this project
25:02
because you're basically building a big kind of mapping between the TPM interface and the PKCS 11 interface. And PKCS 11 comes from the smart card world. So you're basically building an object model, a mapping for an object model between these two things. And it's a pile of work. So a lot of respect to Bill for the time he's put into this.
25:21
We've actually had some folks at Intel not specifically affiliated with us, but working through a partner where we showed a demo at the AWS Reinvent Conference this past year using the TPM as a hardware protection mechanism for your crypto keys in the AWS Greengrass architecture.
25:40
Not something I'm particularly familiar with, but that's nice. That means that we're doing work on the foundation. Other people are picking it up and starting to do useful things completely without our knowledge in some cases. So the easiest way to use PKCS 11 and your TPM for a really big impact on your individual platform, I'm sure people in the room, you log in over SSH to tons of servers.
26:02
I'm assuming you've probably got keys that you're keeping around on your disk. And if you use the PKCS 11 module and OpenSSL, you can keep those keys in your TPM, which instantly prevents you from having someone steal them off your computer and impersonate you on a different computer. And in some environments, if you're an admin
26:21
and you're logging in and your account has a lot of permissions and is very powerful on that system, you really don't want someone being able to get on your system, take your keys, and then log in from another machine. So the TPM can be used almost seamlessly to do that, and we have instructions for going through the setup there.
26:40
And the instructions pretty much break down to this. You can fit all of the commands you would need to do onto a single slide. The default location for the metadata, it's a little bit of a database that maintains this mapping between the two object models. You run a tool that we have that Bill wrote in Python that initializes the entire system.
27:03
You then create a token. Token, again, is a PKCS 11 ism that comes from smart cards. Your token is a physical thing. And in this case, it's a key slot for the TPM in a way. You then add a key to that token. So it's basically like sticking a smart card in a card reader.
27:22
And then when you wanna actually go and use this thing, you just use SSH key gen to pump out the public part, so you can put it onto the server you're logging into. You then insert into the authorized key file there, and it's one parameter that you pass extra into OpenSSL to just have it use the PKCS 11 module for the TPM.
27:45
The login should go just like you would expect from any other SSH login. The TPM tools is actually one of the oldest parts of the project, and it started out as a one-to-one mapping to the old tools from the 1.2 TPM software stack from IBM.
28:04
This was something we ended up doing away with and rewriting entirely. And so there was tons of refactoring in this code base from 2007 to 2008, and it's gotten very, very stable. It started out using just the system API, which is very low level, and we're now, I believe the patches have gone in.
28:22
Joshua has patches that I think got merged that use the ESYS API. They're not merged yet? They are. Oh, they are merged. So now the tools are all using ESYS, which means that we don't have to do any extra work to benefit from using the transport protections from HMAC and encrypted sessions.
28:41
So you can use the TPM tools, and if properly configured, you can get protections for the channel between you and the TPM. This is something that is being used, again, like I was saying in the Clevis project. Red Hat is using these just in a shell script through Clevis to provide an extra pin to get TPM protections in that architecture.
29:06
And this is actually, you know, looking back at past FOSDEMs, the last two years, 2018 and 2017, both had talks with people talking about the TPM software stack. Back in 2007, we have a friend from Facebook, Davide Guerra, who gave a talk that showed
29:22
using these tools and doing just a basic signing operation from the TPM, and then using OpenSSL to verify the signature on the command line, just like you would expect to do. And if you actually go back and look at his talk, it's kind of ugly some of the things he had to do to get the tools to spit out a public cert
29:40
that OpenSSL would recognize. We've gone through and, you know, learned from basically his critique of the tools, and we've gone and cleaned this up drastically. So this is just the set of commands to do exactly that. Unfortunately, there are some things in the TPM that we just can't abstract away, so we have to load a primary key and then create a child key.
30:01
So this is a TPM two-ism that people need to get comfortable with. But after that, all we do is load the key, generate a digest, sign the digest, get it to spit out the public part, and then just use an OpenSSL digest command like you would expect using any other public key. Yeah, and since you wanna be free in what you do with the TPM when you actually start developing,
30:22
because while shell scripts are nice for prototyping, some individual stuff and whatnot, but not very suited for actual productive code or actual applications, while we have C as the primary API of the libraries themselves, but there's also language support for other things. So there's, Google came up with this TPM JS thing.
30:43
If you go to this, their GitHub IO, you can actually use their JavaScript API in the browser in order to do some stuff with a emulated TPM on their end or another thing that we've been working on upstream is coming up with bindings for Python in this case.
31:02
So basically, we're not just going for a CFFI wrapper or CFFI bindings directly. We wanted to get more of the object-oriented parts of Python, of course, into the API, so there's a little object-oriented wrapper around that. And since we're running so great on time, I actually have time to demonstrate that as well.
31:24
Yeah, again, we are, of course, way too small, but yeah, if we just enter Python 3 and we do an, okay, of course, we have to enter Python 3 for that. We import star from pytpm2.tss.
31:43
Everybody should have seen that at some point. We open an ESUS context, and we can already talk to the TPM. There was a TPM command being executed right there, having the TPM generate five random bytes, and then we added some convenience functions in order to unpack them,
32:00
so this would be the actual Python array representation of this TPM2B, which is a TPM-specific data structure of the stuff we did previously. That's how easy it can be. The next one I didn't want to type down, so this would be an actual serious use of TPM. So all the upper part that's pretty small up there,
32:22
that's just, I mean, this is just initializing empty structures that apparently need to be provided to the TPM. Then here we have a few settings, like, well, we want to go for an ECC key. We want to have that key be authorized with user auth. We want to have that be a sign or encryption key, stuff like that.
32:41
It should be an ECDFA signing key with SHA256, and then this P256 curve. Very straightforward. This way we create the primary key on the TPM. What we get back is X, the handle for the actual key, or the other parameters we can actually ignore in this case, and we perform a sign operation,
33:01
and that's it, you already signed something with your TPM. Something that, when you're introducing a topic like the TPM and trying to bring people up to speed on how to use it, when helping people fix things, when it breaks, having debugging tools is particularly important.
33:22
The TPM is kind of opaque to a lot of people, and you send a command and you get a response back, and oftentimes it's an error, it's a little bit of an esoteric error because they're all packed into 32-bit integers, and it's not always the easiest thing trying to figure out what's going wrong when things do go wrong, and things always go wrong.
33:41
So we really just, we noticed this in our work, we ran into the same problems. None of us started out knowing how all this stuff works. We all had to fumble our way through getting started, and one of the things that we realized would be really useful is if we had a tool that allowed us to visualize the command and response buffers, take a look at the command, make sure that it's sending the command
34:00
that we think it's sending, and Wireshark was just the perfect example of doing something like this. So if you're setting up an environment, trying to learn how this works and debugging, you'll run a software simulator in user space, and it communicates with the software stack over an IP socket. So you can configure Wireshark to listen on the communication, and you can get these buffers, but you need Wireshark to do a little extra work for you
34:22
to help you parse through them. And so one of the members of our team, Taddeus Struck, spent a bunch of time in the 2.9 development window doing work in Wireshark to enable the parsing of not just headers, but some of the command bodies as well. You just snip the traffic, like I was saying, and loop back, and you get the capture in the Wireshark UI.
34:41
You can see the headers, you can see it take apart certain command bodies for ones that it understands. We don't have full coverage of the actual, of every TPM command yet, but the talk today is about trying to communicate to folks the benefits of using this technology and help people to get involved. And so if this is something you're interested in,
35:01
if you like looking at ones and zeros all day and network and PCAP files, we would love to have some help actually expanding our support in Wireshark. You wanna jump to the next one, thanks. And so if you see here, this is just the familiar Wireshark window that I'm sure everyone here has probably seen. And since we're communicating over loopback,
35:21
you get the IP headers broken down on the left there. But as you move over to the right, you'll see the protocol is identified as being associated with the TPM, and you'll see kind of request and response buffers being identified. And if you jump to the next one, you'll actually get to see a command body when we actually parse it apart. This is, you know, all the TPM commands are,
35:41
you know, when they're sent to the TPM, they are network byte ordered, they're packed, so there's no padding or anything from any of the C structures that you'll be serializing. So it's really nice to have this tool to go through and pull apart the header like you'll see. A header on all the commands is the same, but you'll see the command code there is identified for the create loaded command.
36:01
That just creates a key and loads it into the TPM in one operation. You can see that we're seeing the handle area and the authorization area. This is something that is just a TPM two-ism, and there's a number of flags and various fields that determine how the TPM will respond to this command. So being able to look at this, and you know, if you don't understand
36:21
why your command produced a certain result, and you think you set a certain number of flags to various values, this is a great way to go through and really identify and make sure that your mental model of what's going on is exactly the model of what's happening in the real world. And so finally, something that is kind of,
36:40
that's just something I was interested in, and I saw this as a potential use case and decided to hack up a prototype, and there was even a talk here earlier. Trusted execution environments, or TEEs, are something that is getting more and more traction across the industry. Pretty much every CPU or major CPUs on the market have some kind of TEE, whether it's trust zone on ARM.
37:01
AMD has SEV for their chips. Intel has SGX, and you know, there's a talk today about RISC-V and what RISC-V is doing for building an environment for their CPU, where the operations for things that are running in this TEE are protected from what we think of as general purpose exploits
37:21
for things that would steal or exploit the kernel, and use that as a way to inspect a process and potentially steal information out of it. So these things are really interesting, and they have the potential to provide us with some really useful tools to build stronger systems, but they're actually quite difficult to work in sometimes.
37:41
TEEs effectively are islands, and you know, if you're on the island and you have everything you need, everything's great. However, as soon as you need something that's not there with you, you have to go out and either bring it in or communicate across the boundary of the TEE to talk to the outside world.
38:01
Interacting with these external entities, like the TPM, has a lot of value and could be really useful, but someone has to build the plumbing to cross this boundary, and someone has to take a look at the added complexity and the risk that comes along with that when you're crossing that boundary, because on one side in your TEE, you are protected, and on the other, it's not. It's basically like sending a network packet over an untrusted network.
38:23
So the prototype looks a lot like what I was talking about in UEFI, it just adds kind of an additional layer, because the TEE itself is, you know, in SGX terms, we call it an enclave. It's this kind of box that I'm drawing here that shows the software stack being used, but when you want to communicate with the TPM, you need this layer here,
38:41
which is just another TCTI layer, to move the command and response boundary, or command and response buffers across the enclave boundary. Once you get across the enclave boundary, you're in the process that's hosting the SGX enclave, and something there needs to provide this glue code to move it that last step across the boundary out of the process, down to the actual TPM itself.
39:02
So we have, just like a lot of things in SGX, you usually have one library that lives in the enclave, and another one that lives outside the enclave, providing support to deal with commands that come from inside the enclave. So there's, in green there, we have the actual TCTI that lives in the enclave. You can build your, the TSS to sit on top of that inside the enclave, and then outside the enclave,
39:21
there's this management layer that catches the commands, associates with them with the connection, and then sends them on down through the rest of the software stack so that they actually reach the TPM. This is very much a prototype. It was really, for me, a way to demonstrate the utility of the TCTI layering mechanism and the separation of that transport,
39:41
and it was also a good way for me to just figure out, how do you build an SGX enclave? What does it mean when I do certain operations and I have to move across this boundary? What are the implications? And so, this work is still very new. The link there is to my personal GitHub account. We haven't merged into the real project or the real community's GitHub space,
40:01
because it's still, it's new, don't have a lot of use cases, don't have a lot of documentation, and I'd really like to write a good threat profile so that people, if they decide to pick this up and use it in their enclaves, they have a full understanding of the potential threats, mitigations that need to be put in place, and the risks that they're taking on by doing this.
40:20
So, if you're interested in developing on TEEs and you think that there's some utility in talking to the TPM, this is probably an architecture that just could be replicated for other TEEs, depending on what their architecture looks like. Yeah, so we've been talking about a bunch of stuff here,
40:42
which had several purposes. First of all, we tried to pick up everybody via some way or another to be interested in this stuff, and to see how useful it could be for them. Of course, it also shows you that this is way beyond everything that a single company could do, so this is actually a community project,
41:01
even though it's still backed by Infineon, Intel, Fraunhofer, Red Hat, we have GE, Bessouza, I don't know, and individuals even catching up and providing our arch user repository builds and stuff,
41:20
we do have a very good bus factor at this point, so even if one of the companies would pull out, would be no problem, so we can say that we're growing into a very stable and very useful software community here, spanning over a bunch of projects. Of course, this is a bunch of stuff already,
41:41
but we also wanted to attract you and everybody else to join us, because this is the stuff that we came up with that would still need support for TPMs, and so if you're involved with any of those communities, if you have any ideas, if you would like to join in and provide patches to Upstream, whatever,
42:02
or if you even know other projects that would benefit from TPM support, which are not listed here, come talk to us, talk to us here, hunt us down somewhere in the cafeteria or the security room or whatever, or talk to us on the mailing list, or get our, I think we didn't provide our email address,
42:21
but you can find them on GitHub and send us a message, and yeah. And if everybody who's leaving is very silent, we can maybe even answer questions now.
42:42
Are there any questions? I would just ask you to stay seated during the question and answer session. If you want to leave, please leave, be quiet and take all the litter with you.
43:03
There is now the internal resource manager with recent kernels. Is there any reason to keep using the user space resource manager? So, that's a good question. First off, the user space resource manager predates the work that happened in the kernel.
43:22
This was just a necessity. We've been providing this software for about three years, and I mean, back then it was very new, but we needed to have some kind of resource management. We politely asked, and were told to provide patches, and it was easier to implement it in user space, and it was also, how to say this,
43:41
so it was the way that it was done previously, and so there was precedent for doing it that way. Now you're right, the work in the kernel is definitely going to be where the resource manager lives in the future, but it is not fully featured yet. So there are still some things that need to be done in the kernel before. Personally, I'm willing to recommend that people use it for, say, long-running systems,
44:02
like a server that's gonna stay up for a very long time. There are some weird things you have to do to keep the TPM happy. If you're interested, there's this notion of what's called a context gap. It's an anti-replay mechanism that exists in the TPM for when you're loading and unloading sessions, and that's currently not supported in the kernel yet. We've been talking to Yarko about that work,
44:22
but it'll happen when it happens, and until then, personally, I'm recommending the folks use the one in user space because it does support that mechanism in the most recent release. It's also useful for when we're testing. So you run a simulator in user space. If your only resource manager code is in the kernel, really hard to test the real life scenario.
44:45
So I agree, ideally in the end, there will be no user space resource manager used in deployed systems. It may live on as some kind of proxy daemon that can do enforce policy if you're on a system where you wanna have blacklisted commands where you don't want any of those
45:01
going from user space into the TPM, maybe only something that the kernel would do. You could provide that in a layer that's outside the kernel. Putting policy or mechanisms in the kernel, a lot more tricky than just doing it in user space. So I agree, but I think we're not there just yet. We're really close.
45:20
Hi there. This is a bit more of a policy question. Basically, while you're building this community around this technology and its potential applications, I'm really intrigued in particular in the BitLocker-esque functionality of keeping your disk encryption keys in the TPM. Are you talking to relevant standards bodies and so on
45:43
about getting this approved as a secure way of storing keys in the hope that Linux will be usable in more secure environments? I didn't get the middle of the question. Sorry, are you talking to relevant standard bodies
46:00
by people like the cybersecurity essentials in the UK to try and get some of this TPM usage in Linux, allowing Linux to be used in more secure environments? So I mean, the TPM itself lives in a standards body. They define both what the TPM is, the interfaces to it, and the software stack is part of what we've been
46:22
driving in that direction. As far as the individual uses, so knowing whether or not the implementation that's using Lux or Clevis or whatever else, whether or not that's acceptable to various standards, I think it's an eventual end goal. I don't necessarily know that that falls under the purview of the open source community
46:41
that we're building around the implementation. They're definitely the people that would probably be implementing it and possibly responsible for taking patches that would bring it in line with these standards bodies. It's definitely not something I'm opposed to, but it's definitely not a primary concern at the moment. We're more interested in just getting people to use it, use it effectively to protect their stuff as best they can
47:00
and if it does gain traction, I imagine that would happen just by virtue of its own utility. They think it's useful in those spaces, they wanna make sure that it works properly, and eventually other people will take a look at it, I hope. Hello, I'm Brian Paulson. One of the biggest stumbling blocks I had when trying to integrate TPMs into my projects
47:22
is that the documentation for libraries are non-accessible. The GitHub products doesn't need a link to documentation. Are you trying to resolve this problem? Andreas, you like writing documentation.
47:41
I didn't understand the question. Let me repeat this just to make sure I understood it properly. The documentation is pretty bad, sounds like what you're saying. There's actually a pile of books, there have been three or four published books that are three, 500 pages, and I agree, they're almost impenetrable.
48:01
You read them and it's very deeply, it's steeped in jargon from the standards body. I think that the thing that's been preventing us from getting.