Improving security of the FreeBSD boot process
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 | 34 | |
| Author | ||
| License | CC Attribution 3.0 Unported: 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/45162 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
1
2
3
4
7
8
10
14
15
17
18
22
23
26
28
31
32
34
00:00
Information securityBootingBootingDocument management systemProcess (computing)ImplementationPresentation of a groupSoftwareComputer hardwareMalwareChainComputer-generated imageryMountain passRootkitFlash memoryBootingCASE <Informatik>MalwareDatabaseProgrammable read-only memoryMedical imagingForm (programming)RootkitElectronic signatureLevel (video gaming)SoftwareFormal verificationVirtual machineElement (mathematics)Read-only memoryInformation securitySign (mathematics)ChainBefehlsprozessorImplementationPhysical systemMereologyPresentation of a groupComputing platformVirtuelles privates NetzwerkComputer hardwarePlanningBootingPublic-key cryptographyOpen setArithmetic meanMultiplication signSemiconductor memoryNetwork operating systemComputer animation
05:12
Document management systemSource codeSoftwareComputer hardwareMessage passingFile formatImplementationBinary fileCompilerBootingComputer-generated imageryDirectory serviceDensity of statesEmailTable (information)Standard deviationSign (mathematics)Public key certificateChainPublic-key cryptographyElectronic signatureOrder (biology)NumberLibrary (computing)Electronic mailing listPointer (computer programming)File formatBinary codeMedical imagingSoftware frameworkDirectory serviceAlgorithmMessage passingRSA (algorithm)Open setMenu (computing)System callWordCellular automatonPasswordComputer animation
07:24
Variable (mathematics)DatabaseComputing platformHierarchyLatent heatDocument management systemSoftwareComputer hardwareBootingInformation securityPublic key certificateKey (cryptography)DatabaseSchlüsselverteilungComputer configurationCASE <Informatik>Validity (statistics)Direction (geometry)Computing platformVirtual machineDefault (computer science)FirmwareData storage deviceVariable (mathematics)Integrated development environmentFormal verification1 (number)HierarchyMathematicsLevel (video gaming)Musical ensembleBootingPublic-key cryptographyMedical imagingRight angleOperator (mathematics)Computer animation
10:24
SoftwareElectronic signatureDocument management systemComputer-generated imageryComputer hardwarePresentation of a groupDatabaseBinary fileKernel (computing)Scripting languagePoint (geometry)MetadataSingle-precision floating-point formatComputer fileImplementationMatching (graph theory)DatabaseModule (mathematics)Information securityUser interfaceLevel (video gaming)AlgorithmFormal verificationMedical imagingVulnerability (computing)FirmwareMereologyValidity (statistics)Library (computing)BitPhysical systemKernel (computing)1 (number)Scripting languageComputer fileMultiplication signBootingAdditionFluid staticsElectronic mailing listRead-only memoryOperator (mathematics)RootkitSoftware frameworkFerry CorstenAuthenticationFlagInterpreter (computing)HypermediaMusical ensembleMultiplicationBinary codeWeb pageDegree (graph theory)Patch (Unix)Open setPublic key certificateComputer animation
15:28
ChainDocument management systemKey (cryptography)Library (computing)CryptographySystem programmingElectronic signatureVariable (mathematics)BootingSoftwareComputer hardwarePresentation of a groupInformation securityMereologyRing (mathematics)Public-key cryptographyBootingKernel (computing)Physical systemPersonal identification numberImplementationPublic key certificateArmProduct (business)Minimal surfaceRun-time systemSpacetimeComputing platformModule (mathematics)Communications protocolProjective planeComputer configurationComputer hardwareNumbering schemeRevision controlCompilation albumLibrary (computing)Key (cryptography)CryptographyElectronic signatureSign (mathematics)CASE <Informatik>Formal verificationTerm (mathematics)Computer fileBridging (networking)Resolvent formalismFlow separation1 (number)Conditional-access moduleBus (computing)Uniform resource locatorVariable (mathematics)System callBuildingLocal ringDatabaseBootingMemory managementWeb browserCellular automatonLipschitz-StetigkeitFrequencyLogical constantMultiplication signFunctional (mathematics)Form (programming)AlgorithmInclusion mapCodecDifferent (Kate Ryan album)Computer animation
22:23
Computing platformModule (mathematics)Computer hardwareData integrityBootingAuthorizationData storage deviceRandom number generationDocument management systemSoftwareCryptographyVorwärtsfehlerkorrekturOperations researchRSA (algorithm)Advanced Encryption StandardOperator (mathematics)AuthorizationEntropie <Informationstheorie>TelecommunicationDescriptive statisticsBus (computing)Computer configurationPhysical systemPasswordData storage deviceComplex (psychology)Default (computer science)Interrupt <Informatik>Numeral (linguistics)Connected spaceCASE <Informatik>Key (cryptography)Source codeRSA (algorithm)MicrocontrollerPublic-key cryptographyMeasurementFood energyPower (physics)FirmwareMinimal surfaceVulnerability (computing)CountingIncidence algebraBootingInheritance (object-oriented programming)Revision controlElectric generatorLevel (video gaming)BefehlsprozessorCryptographyComputer hardwareRandom number generationInternetworkingWhiteboardDeterminantResultantDirection (geometry)Computer animation
27:00
CryptographyAdvanced Encryption StandardVorwärtsfehlerkorrekturRSA (algorithm)AlgorithmRule of inferenceComplex (psychology)AuthorizationDocument management systemSoftwareComputer hardwareSoftwareElliptic curveEncryptionAlgorithmSlide ruleFunction (mathematics)AuthorizationCASE <Informatik>Object (grammar)CodeMultiplication signMaxima and minimaDifferent (Kate Ryan album)Revision controlComputer configurationLengthKey (cryptography)NP-hardLibrary (computing)Latent heatGoodness of fitWordLevel (video gaming)Patch (Unix)Rule of inferenceComputer animation
29:03
IntelArmTime zoneMobile WebBefehlsprozessorDocument management systemSoftwareComputer hardwareFirmwareRandom number generationComputing platformModule (mathematics)Data integrityBootingAuthorizationData storage deviceVorwärtsfehlerkorrekturAdvanced Encryption StandardCryptographyRSA (algorithm)Operations researchSlide ruleMultiplication signPersonal identification number2 (number)WhiteboardPlotterNumberControl flowPhysicalismImplementationSoftwareTerm (mathematics)Physical systemInformation securityRevision controlSide channel attackEntire functionSemiconductor memoryCodeParameter (computer programming)Minimal surfaceBefehlsprozessorArmKey (cryptography)System callComputer animation
31:16
Smart cardRootkitEnterprise architectureProof theoryData integrityIcosahedronIPSecVirtuelles privates NetzwerkData storage deviceSystem programmingBootingEntropie <Informationstheorie>Physical systemFreewarePersonal digital assistantDocument management systemSoftwareComputer hardwareAuthorizationRule of inferenceNon-volatile memoryLimit (category theory)PasswordPersonal identification numberComplex (psychology)Revision controlDigital rights managementIntelMinimal surfaceDifferent (Kate Ryan album)EncryptionRepresentation (politics)IPSecPasswordArithmetic meanRandom number generationState of matterProjective planeDifferent (Kate Ryan album)Numbering schemeMultiplication signMedical imagingRemote procedure callDigital rights managementComputer configurationImplementationMinimal surfaceFirmwareForcing (mathematics)Key (cryptography)EncryptionComputing platformObject (grammar)Sign (mathematics)CASE <Informatik>Message passingNeuroinformatikAxiom of choicePlastikkarteCryptographyHypermedia1 (number)Term (mathematics)BootingPhysical systemTelecommunicationData storage deviceGeneric programmingMenu (computing)Server (computing)MiniDiscMereologyConfiguration spacePhysicalismPersonal identification numberVirtual machineLatent heatINTEGRALInformation securityPublic key certificateVariable (mathematics)MalwareSpacetimeRule of inferenceSemiconductor memoryAuthorizationLevel (video gaming)Workstation <Musikinstrument>Complex (psychology)UsabilityPoint (geometry)CodecMusical ensemblePerpetual motionEnterprise architectureLetterpress printingComputer programmingCuboidGoodness of fitBuildingMetric systemOffice suiteLimit (category theory)Order (biology)Operator (mathematics)MathematicsComputer animation
39:27
Complex (psychology)Revision controlDigital rights managementIntelMinimal surfaceDifferent (Kate Ryan album)EncryptionDocument management systemSoftwareComputer hardwareBootingPresentation of a groupMilitary operationComputing platformVirtual machineSource codeLink (knot theory)BootingInclusion mapPhysical systemData managementForceFormal verificationGroup actionSoftwareIntegrated development environmentConfiguration spaceEncryptionPhysicalismLibrary (computing)Extension (kinesiology)ResultantDoubling the cubeEmailDifferent (Kate Ryan album)Personal identification numberObject (grammar)Endliche ModelltheorieMotherboardBootingEnthalpyState of matterMathematicsArithmetic meanRevision control1 (number)Bus (computing)CASE <Informatik>SequenceInformation securityVariable (mathematics)Functional (mathematics)TelecommunicationMeasurementMedical imagingComputing platformPhysical systemMereologyRow (database)Key (cryptography)Process (computing)InformationVirtual machineFirmwareComputer configurationMultiplication signOperator (mathematics)Nichtlineares GleichungssystemBitService (economics)Similarity (geometry)Cache (computing)FreewareVideoconferencingRight angleMusical ensemblePolar coordinate systemComputer animation
47:39
Physical systemData managementBootingSoftwareGroup actionDocument management systemComputer hardwareFirmwareBootingDatabaseMeasurementEvent horizonMilitary operationExtension (kinesiology)Operations researchBinary fileModul <Datentyp>Kernel (computing)Presentation of a groupInternetworkingCommunications protocolPublic key certificateAuthenticationComputer wormImplementationIPSecCross-platformSource codeEncryptionIcosahedronLine (geometry)Patch (Unix)Library (computing)Discrete groupTuring testKey (cryptography)Virtual machineDataflowBootingSoftwareFirmware1 (number)State of matterMeasurementExtension (kinesiology)Configuration spaceElectronic mailing listObject (grammar)Event horizonBefehlsprozessorSign (mathematics)Library (computing)Source codeCommunications protocolImplementationWind tunnelAuthorizationBootingComputing platformBinary codeRepository (publishing)MereologyInternetworkingOperator (mathematics)WebsiteKey (cryptography)2 (number)Public-key cryptographyNumbering schemeOpen sourceNichtlineares GleichungssystemComputer fileResultantAuthenticationSchlüsselverteilungAdditionCuboidKernel (computing)Public key certificateMusical ensemblePoint (geometry)Module (mathematics)Minimal surfaceComputer animation
53:14
Link (knot theory)Public key certificateDocument management systemSoftwareComputer hardwarePasswordObject (grammar)Plug-in (computing)Configuration spacePhysical systemComputer configurationComputer fileMereologySign (mathematics)Key (cryptography)Computer animation
54:05
Entire functionSoftwareComputer hardwareDocument management systemOrder (biology)Scripting languageString (computer science)WebsiteCodeMultiplication signSelf-organizationWindowINTEGRALFrequencyTotal S.A.Set (mathematics)Pairwise comparisonPatch (Unix)Limit (category theory)Object (grammar)Booting1 (number)NumberIntegrated development environmentMinimal surfaceStructural loadTerm (mathematics)System callControl flowProcess (computing)PasswordComputer configurationOperating systemContent (media)BootingVirtual machineWeb pageComputer hardwareKernel (computing)Point (geometry)Mechanism designResultantImplementationBitComputer fileModule (mathematics)RootkitOperator (mathematics)Computing platformAuditory maskingStandard deviationFerry CorstenSlide ruleEncryptionMiniDiscProjective planeGoodness of fitCompact spacePower (physics)Chemical equationCache (computing)Coefficient of determinationComputer animation
01:00:54
Document management system
Transcript: English(auto-generated)
00:12
Thank you for coming. My name is Mikael Stanek. I work for a company called Semihab. I'm going to talk about some security additions, which we have been working on.
00:23
I think 3BSD, mostly regarding to the boot process, but those are some other things. Most of the work which we have done is already available in 3BSD head, so we can all use it. The plan for the presentation consists of roughly three parts.
00:41
In the first part, I will explain secure boot, especially with regards to the UEFI implementation of secure boot. This is something which we wanted to have, and our customer wanted to have in their systems. Along with 3BSD very active, which is another security layer which we wanted to use.
01:03
Originally implemented by Juniper, that is JG from Juniper. Talking about how we integrated the rigs into a UEFI to suit our systems. The third part will be about trusted platform modules, so TPMs. I will explain what they are, what they are used for, what are the possible use cases,
01:24
what are the use cases which we considered and used. One of them being the most common one being the measured boot. And as one of the most interesting use cases for us, I will explain how to use StrongSwap,
01:42
IPsec, VPN implementation, hardened with the TPM. In fact, the TPM does the signing in this dedicated separate hardware instead of the CPU. Three parts. Let's start with secure boot, secure boot 1 to 1.
02:02
What is the purpose of secure boot? Basically, the purpose is to only allow authenticated firmware, NOS and other elements to run. Each element in the boot process, each image has to be verified.
02:21
And only if it is successfully verified, it will be allowed to run if secure boot is enabled. So it's kind of a defense against rootkits and malware which cannot be persistent on a secure boot machine, hopefully. So if the attacker supplies some kind of rootkit, it modifies any boot image like the bootloader or loader or any part.
02:46
On next boot, this will not have a very valid signature, so it will not execute. A secure boot forms a chain of trust, it's called a chain of trust starting with something called the root of trust,
03:01
which is the first element, the first software that runs in the machine. And the idea is that each image, before it passes execution to the next image, and the next is the bootloader, it has to verify it first. So it uses signatures, database of X.509 signatures that are allowed,
03:20
and it verifies the signature, and only if it passes will it pass execution to the next stage. Otherwise it will fail. So each image verifies the next number. So this first boot image is called the root of trust, and obviously it is not verified by anything, it has to start somewhere.
03:43
So this first image has to be immutable, it's very important that it's implemented in read-only memory. So there's a hardware-based enforcement that this software cannot be modified. So it usually is just burned in by the vendor, and it's not ever updated.
04:02
So the attacker cannot modify this one. So you can only really attack it in the root of trust, however each next image is verified so you cannot get in there and implement some malicious software. So this is an example of set-between.
04:21
Starting with reset, you have something usually called a bootrom, which is this first small piece of software it runs. And another thing is that for verification you mean to have a reference public key, which we are going to verify with. And this also is very important that it's protected from identification,
04:43
because otherwise the attacker would supply their own public key, and the verification of the malicious software would succeed. So very often technologies like one-time programmable memory, or e-fuse, are used for that. So you have a burned-in public key, which cannot be modified,
05:02
and it is in a fixed location, so it will be the reference for all these verifications at each and every step. So just a quick reminder of how verifying and signing works. In the public key cryptography, you have a message,
05:20
you hash it with a particular cache, the signer has access to the private key, and whether you are using RSA or VSA, you are using a signature algorithm on this hash, and you end up with a digital signature, which is supplied with the message, bundled with the message somehow. I'll be talking about how it's done in UEFI.
05:42
You have a signed message, so it can be a piece of framework with a signature, and in order to verify it, you have to have access to this public key. For verification, you separate it into message and signature, you hash it the same way, with the same algorithm,
06:01
which is usually used in UEFI, and then you use the public key with the signature algorithm for verification, and you either pass or fail. So how is it implemented in UEFI? For better or worse, UEFI uses the Microsoft PECOP format for its binaries,
06:23
which it can run. And PKE does something called PKCS7. It's a format for signatures, which can be bundled with those binaries. You have a binary, which is a piece of framework, and the signatures are bundled according to this format.
06:46
OpenSSL is one of the few libraries which supports this format. The common UEFI implementation, which is EDK2, is compiled with OpenSSL, and that's how it can be verified.
07:01
Here's just an example. This is a binary format, and you have a pointer, and an image data directory entry number 5, pointer to the certificate table, and then you have, on the left side, a list of certificates, the whole chain of certificates, because you can, just like in TLS,
07:22
people have chain certificates as well. Something very important in security in UEFI are the databases of allowed certificates, and also blacklisted certificates. So I'll just very quickly explain.
07:43
Without going into too much detail, the terminology, what are the main critical environmental variables, because the databases are stored as environmental variables in UEFI. So DB and DBX are the
08:01
whitelisted and blacklisted certificates. So DB is the database of certificates which are allowed, and DBX are the forbidden ones. Apart from certificates, you can also use direct hashes. So the DB and DBX can also,
08:21
apart from certificates, store direct hashes which are allowed or not allowed, so hashes of some firmware or any image. So first you check with DBX if what you're trying to verify is blacklisted. You check its hash if it's there,
08:40
and then you don't have to do a certificate because it's more direct. Otherwise you have to deal with certificates and do the whole verification. So there's a key hierarchy in UEFI, and the one at the top is called Platform Key. You might be familiar with it if you saw these options in UEFI footloader.
09:03
You can change your PK, change your PK. So the PK is at the top, and it's owned by the platform owner, and it's not supposed to be updated very often. It is allowed, some of it, access to the PK private key, can do any modification to any of these variables.
09:23
So it's the highest level of privilege. However, we mostly use the key exchange keys. And the key exchange keys, if you want to modify them, add a new one, or a new one, or modify, you have to assign this operation, the someday operation, with PK.
09:42
Very often on modern platforms you might have seen the Microsoft Key UK, which is usually just by default in there, but hopefully your machine is not locked down, you can have your own one.
10:01
And again, if you want to update anything in DB or DBX, you have to assign it to either key UK, any key UK in the list, or PK. And as I said, you can, apart from certificates, you can do just hashes, which is less convenient, but if you don't update your firmware very often,
10:22
you can do that, it's a valid use case. So that's very quickly how the algorithm works for verification. You have the image first, the first image which you're trying to verify. First you just check for the hashes. So check the blacklist.
10:42
If there is a match with the blacklist, you immediately pay off. Because it's just not allowed, you can revoke bad firmware that way, firmware vulnerabilities. Otherwise, you check in DB, and if you have a match with DB, that means it's whitelisted and you just succeed. You don't have to deal with certificates,
11:02
there's a valid match in DB. Otherwise you deal with certificates, so you check with your trust designer, keep null, then we fail, again DB and DBX. And then we do the whole verification, if you have a match with DB, so if there's a match, you succeed.
11:23
So this was about UEFI. However, there was, this is a very basic layer which we wanted to use. So first we wanted to just be able to verify the kernel, the BSD kernel, make sure it is trusted.
11:40
However, we saw this very basic thing, which was I think originally in that BSD. And we saw that we can not only verify the kernel, the loader can be able to verify the kernel and the module's authenticity, but also we can verify parts of user interface. So a very exact verified execution
12:00
is a layer where you can, if you have a list of files, how fast, doesn't have to be binaries, and their hashes. And again, you have whitelisted a list of hashes in binaries, and the kernel itself will not allow opening or executing
12:20
such a binary or file if it's not in the list, if it's hashes not in the list. So as I said, it was created by Juniper, or Junos. We cooperated with Simon from Juniper so that we have a common library for using that,
12:42
whether you're using a system with UEFI or not. Juniper, originally, they're not using UEFI. I think our implementation with UEFI, if you want to use UEFI, it's kind of simpler to use because you have access to these databases and easily revoke.
13:01
So we're really happy with how it works, and since February 2019, all of the very exact implementation is in PBSDF. This reference file for verification is called the manifest in the very exact. And this is this list of files and their hashes, which are allowed.
13:23
The idea for very exact is just to prevent executing any malicious or untrusted binaries, kernel, or scripts. So it's very well suited for embedded systems, for example, where you're not modifying much, maybe you have a static read-only file system,
13:44
so it's an additional level of protection that even the root user will not be allowed to execute untrusted files. So there are basically hooks at certain system calls, like exempting or open,
14:02
the main ones. Of course, it introduces some overhead, so the kernel has to, before it allows, the open or the exact to pass through the verification. You can cache these caches, so you only verify once, and then it prevents further modification. So it introduces some overhead,
14:22
but I think it's a pretty good trade-off of this kernel-enforced verification. I've already said that the manifest contains just simply passing and hashes and also some flags, because you have to differentiate between a simple binary, which it directly executes, or maybe it's a script for an interpreter,
14:42
so it gets quite complicated. The kernel then builds this database of these paths, which are the key, and then the hashes. Each time the file is loaded or trying to be executed, you search for its hash.
15:01
If there's no match, you just fail the operation. So there are certain different levels which you can configure where it's equipped. The lowest one is just that there will be a warning if there's a mismatch. The higher the security levels are, it will just fail the operation.
15:21
It's a bit more complicated than that, but I think it's all in the man page. So now, if we are using UEFI and Prairie Exit, we have this manifest, which is not part of the trust chain, and it's very important for security, because this is our reference.
15:41
We do not want an attacker because that would just fill our security and just supplant their own hashes. So we do have to verify it somehow. We saw that we can use these trust anchors from UEFI for this,
16:01
which is really, really convenient. The manifest file is usually at a fixed location, and in a separate file in the same location is its signature. In essence, we are doing what we did before. We have access from the loader to the DB and DBX and all the other variables,
16:24
because UEFI exports it with a get variable runtime system call. So it's very easy to do. We retrieve the databases, and we use that as reference for the verification.
16:41
One problem which we have to resolve is we needed those crypto APIs, we needed to have crypto in the loader and in the kernel later on to be able to verify. Of course, the loader, we want it to be small, we want it to be lightweight,
17:00
we don't want to pack OpenSSL in it. So then we found something called VerSSL, which is this really nice library which is super lightweight. It has, surprisingly, a lot of functionality, especially in terms of TLS, but the part which handled the verification
17:21
and sign that was, first of all, parsing the next file online. The certificates, that was all working, and it was fine for our use, so we decided to incorporate it in the loader. This library was made by just one guy, and we wanted to have some kind of
17:45
a very lightweight library for embedded systems. The key advantage of VerSSL is it does not use dynamic allocation at all. It's also pretty modern, so it uses constant-time algorithms, so that's pretty cool.
18:02
That's really what we did. We added the compilation option to include VerSSL so that the loader can use it on the kernel, and we're using it for very exciting. The library, which we ended up making with Simon from Juniper,
18:21
that's called libsecurebook. It's defined in libsecurebook, and it depends on VerSSL. There's no alternative as of now. If you don't want to use UEFI and certificates like Juniper, we added static keys as they were using.
18:41
I think they were also using some PGP scheme for this, but I think this implementation of UEFI is really nice because you can easily just reroll things using PBX. You can do it from user space. You can do it directly in the BIOS. It's really, really convenient and quite simple in the implementation.
19:06
The next part, actually this was the key part in our project. The project started when our customer wanted to have a security certification for their products.
19:20
I forgot the actual name, but it had to involve a TPM. Basically, they were doing a lot of IPsec, which was a strong fund. The idea they had was to use the TPM to sign the certificates for IKE in the initial IPsec negotiation so that the private key is not stored on the system,
19:42
but stored inside a dedicated separate hardware device. Similarly, if you are familiar with UB keys, again, you have a hardware security module where the private key is embedded in this module.
20:03
You just initiate signing requests to it and it will sign things for you in the private key. There are a lot of other use cases as well. Very quickly, about how the TPM support looked in FreeBSD.
20:21
There are two different versions of this pack. The trusted platform module is packed. It's 1.2 and 2.0. These are the ones that are really used. The previous ones were deprecated and not really recommended. The TPM 1.2 driver was directly introduced in 8.2.
20:41
However, we wanted to use TPM 2.0 and I will show you why. It's a good idea to migrate to TPM 2.0 if you can. We wanted to use TPM 2.0. We made the driver last year.
21:00
Both low-level protocol modes, CRB and FIFO, are supported. However, they are only supported for Intel systems as of now. If you're familiar with the LPC bus, that's the low pin cam bus. It's something like ISAT, I think, and it's only available on Intel systems. I think it's on the south bridge.
21:23
This is really the most common TPM implementation. Our implementation is using just the generic, embedded I2C and SPI buses. We have some ARM systems which we are also working on. They use TPMs, but they have to use the I2C.
21:40
Also, you can buy an adapter board, which translates these protocols. The driver we made for FreeBSD currently only supports the LPC. There would have to be a separate drive for I2C and others. The particular TPM which we are using
22:00
was by Infineon, which I think is the most common vendor of TPMs. It's 96665. I think it supports both 1.2 and 2.0. Some vendors don't make you buy a new TPM from 1.2 to 2.0. They just give you a different firmware for it. All it really is is a microcontroller,
22:27
some exotic architecture, something like 16-bit. You also have to update the firmware on it. That's something that people forget. There are vulnerabilities found in TPM firmware.
22:41
Infineon has a few ethnic incidents. You should really make sure if you get one that you update the firmware. One thing that was the main idea behind TPMs was that they were supposed to be cheap,
23:01
like really cheap. The idea was to have them included in all systems, even small embedded systems, for every cent counts. That was realized. If you look at the prices of TPMs, I was actually really surprised how cheap they are. If you're just buying one,
23:21
you can buy one from something from $1 to $5. If you go on DigiKey or Farnell or whatever, they're up to $5 apiece. If you buy hundreds of them, I think the lowest you can get is $0.40 per chip. You can actually pair the whole board
23:41
with the connectors and stuff. It's really cheap. As a direct result of that, it's really slow. Do not treat it as a crypto accelerator because if anything, it's a decelerator. It's super slow, but that's the way you're going at it.
24:02
The idea is that it's simple and it can be integrated into all systems. I think they're so versatile. If you look at the specs, they're really fond of everything, almost. Apart from this major boot, which is maybe 90% of the use cases for the TPM,
24:22
you can have square storage, really complex authorization policies, which I'll explain later, especially in the 2.0 version. You can generate keys on it, like a UDP. You can use it as a hardware random number generator. We did something we also did for FreeBSD.
24:42
We can also use it as an RNG. Obviously, it will not be the only source of entropy on the system. We decided to just mix in the RNG, the entropy from the TPM, into the general OS entropy pool.
25:02
I think it's disabled by default on AMD64, but currently, if you're running that, you can enable it for yourself if you want. I think it's worth noting that this is really important for embedded systems, where entropy is hard to find, especially in the other stages of the boot. I think it's really, really crucial
25:22
to have a hardware-based source, at least in a mixed-in. Otherwise, you might run into trouble if you're trying to generate keys early on. We will have a lot of determinism there in the Kubernetes, lots of embedded devices, pingable on the internet.
25:41
Some of them have similar keys, even though they are not related due to this determinism, lack of interrupts and so on. One other thing that TPM can do, it can do general crypto. Let's spend it depending on the TPM. However, the private key operations are mandatory for TPMs.
26:03
It must be used for RSA. In the newer one, you have ECC, that occurs. In some of them, you have AES, so you can just give it stuff to encrypt symmetrically. It has to support SHA and HMAC,
26:21
which is partly for encrypting the communication with the TPM. This is actually possible to encrypt and MAC communication from the CPU to the TPM, which is something not a lot of people know. Not a lot of people know that there's an option, like Microsoft didn't know. For BitLocker,
26:42
they're using TPMs, but they're not using description. You can just sniff on the bus, which is easy because it's slow. If you look at the spec, there's quite a lot of options. They're mostly known for the measured boot. However, there's much more things you can use.
27:01
In a few slides, I'll show you the use cases that are coming. Very quickly, the difference between the versions. This is important in that most software is supporting the 1.2 because it was made 10 years ago. Most of the software supports 1.2.
27:22
Not all software, and even libraries, not all options of the 2.0 are supported. You have to watch out for that. However, it's getting better. The reason why you should really not be using 1.2 is it was overall a pretty good spec, even though it was really hard to read
27:40
and maybe that's why people were put off. It was pretty complex. I think the biggest downside of 1.2 is that it has hard-coded algorithms in the spec. The idea they had is to hard code SHA-1 as the reference hashing. This is obviously not good for today's times.
28:03
It wasn't good 10 years ago. There's no way to circumvent that. It's in the spec. Also, there's no elliptic curves. RSA2K is the only one. AES encryption is optional. In 2.0, they fixed that
28:22
by introducing algorithm availability. There's not one specific algorithm that's burned in in the spec. There's only the maximum key and hash length in the spec. In practice, you have SHA-256, SHA-512, you have RSA output 4K, you have elliptic curves,
28:41
and very often you have AES at least 128. Just 2.0. I'll be talking in a few slides about authorization rules, which you can use for objects stored in the TPM. I think it's really flexible. Important to note, they're not backwards compatible.
29:01
They're very different in specs. You saw two slides ago how the TPM usually looks when you buy it. It can be pluggable and soldered on the board. I was thinking that if you can get the pluggable one, you might be susceptible to an evil-made attack when somebody has a sniffer
29:21
which matches the pins. In five seconds, you can swap in the sniffer and sniff all the communication. That's why it's useful with this trust encryption. When it's soldered, it will take more than a coffee break However, it doesn't have to be this discrete device. The TPM doesn't say much
29:41
about the physical implementation really. It's up to the vendor. You might as well have a former TPM. This is actually, in terms of deployment, the most deployed one. If you check your BIOS, very often you'll see something called tech TPM.
30:01
This is now supported by Intel systems and AMD systems. Intel does it in Intel ME, whether you like it enough or not. AMD has something that's pretty equivalent to Intel ME, which is PSP, and it also has a TPM in it. We discovered that it's
30:21
maybe a butchered version of the TPM, so it doesn't support a lot of things, but the upside of using it for more TPMs has these performance issues, because it really runs on your CPU. Maybe in a privileged mode, like we work a lot on ARM systems at Semicap. They use TrustZone,
30:41
which is this secure world hardware-based isolation for memory and for devices and for code. You can put the entire TPM software in TrustZone and make SQL calls into TrustZone, and it's almost as good as a separate discrete device.
31:00
Although you might argue that we have these side-channel attacks these days, and if it runs on the same CPU, the big pikis might still leak, so maybe that's another argument to use those discrete TPMs, even though they are slow. So some interesting use cases.
31:21
Of course, they are quite adorable in the enterprise, because you can use them for disk encryption. You can do remote attestation, so it's similar to how some SGX can't play. So basically, the TPM with the metric boot bar,
31:41
it proves a certain platform state. I'll be explaining what it really means. It can prove to remote agents, remote server, that a system has a specific platform state, and the server knows that
32:01
this state is trusted, and it can continue communication and perhaps provision some keys or do whatever. So in essence, the TPM stores the platform state in terms of cryptographic hashes of different images that were executed during boot, and for remote attestation,
32:22
there's an option for the TPM to sign this, along with the nonce to prevent replays. So this is very useful for enterprise. However, it's not so widely deployed, I think. Another thing you can use the TPM with is similarly to a YubiKey,
32:42
you can use it as a smart card, like GPG. You can sign messages with the key, which is embedded with the TPM. So the private key never leaves the TPM. You have to put it in there in the initialization stage, but after that, it never leaves the TPM. Only signs what you want it to.
33:01
I'll be talking about IPsec DPM, how you can do the same thing with IPsec. A very common use case these days, especially since BitLocker from Microsoft supported it, was just storing these encryption keys in there, so tying it to the TPM.
33:24
Linux LUKAS also supports it. Unfortunately for DSD, GUI does not support it yet. We'd like to have that happen. However, our customer was not using this, I think, so we didn't work on that. A really important advantage of using this TPM,
33:44
apart from other security solutions, is that it supports anti-hammering. If you're just trying to brute force your password to the pin, to this encryption key
34:01
or any other thing that's in TPM, there's a hardware-enforced anti-hammering scheme where you fail a few times until it does enter a lockdown. Either you have to wait a long time for it to reset, or you need to supply something which is called the owner password.
34:23
It's something which you set up when you provision the TPM. You buy the TPM, you have to set it up with an owner password, and you're not supposed to use it much. You're supposed to store it somewhere safe, and this is what we're patriotic about now. So it prevents brute forcing and dictionary attacks.
34:42
As I mentioned on the first slide, you can store the trusted brute keys with certificates in the TPM. There's not much space for it. Most TPMs, like Anthony and I showed you, I think it has something like 10K memory, 10K memory around this, 10 kilobytes. It's not locked, but
35:02
yeah, what you want to do. These are keys. And RNG for the OS, which we did in the TPM 2.0 project. So I was talking about the ND RAM. You can put your keys in the ND RAM, or any kind of data, really.
35:22
And it will be a separate object, and for each separate object in the ND RAM, you can implement a very complex authorization policy. So it's not only required that your TPM is in your computer. For each object, you can define different rules for accessing. So if these rules are not met,
35:41
the TPM will just not give you the key or the object. It will just refuse. And these can be combined with AND and OR in the 2.0 spec. So they can be really complex. The options which you have, I think there's more than just these, but of course you can have a password
36:01
to just send the password on the TPM as means of authorization. You can have a pin code. You can have eight MAC to the pre-shared symmetric key, which is both in the TPM and in your system. A very important one is the PCR state.
36:21
So this is this representation of the platform and boot integrity. So if the PCR state is different than the trusted one, which is remembered by the TPM, it will not disclose the keys as well. This is what is used very often for disk encryption. Like BitLocker uses it
36:40
in the simplest state. So if there's any malicious software any modification in the firmware or there could be also you could also include in this PCR state some configuration like to identify environmental variables. The menu part changes.
37:02
The TPM will notice and it will not give the keys. Physical presence is another one. It can be just a separate pin on the chip which you connect to something like your button. Or maybe it could mean just some BIOS access depending on the implementation. Like direct access to the BIOS menu.
37:21
You have counters, you have time limits, lots of other things for those. So you can configure it as you like. Some problems with the TPMs, quite a lot of them, but I think they're pretty useful. Initially there were some concerns with anonymity in terms of this remote attestation.
37:41
So in any remote attestation scheme you have to take care of anonymity. Otherwise the remote server might identify you personally, like identify your machine and you might not want that. So in 1.2 they introduced something called DAA, I think direct anonymous attestation,
38:00
which is something like the zero knowledge proof, which only tells you that during remote attestation that you're part of a group. It does not identify you directly. There were some DRM concerns ten years ago or so when these were introduced. And they could be used for DRM and locking down your platform
38:21
and stopping you from being the owner of your platform and deciding for you I think for generic media DRM, TPMs are a really bad idea to use with DRM, especially since Intel M.E.
38:41
and SGX came out, especially Intel M.E., where you have actually DRM running in Intel M.E. like Netflix and others and this just meant much better to be suited for DRM. So I think this concern is valid these days, and I haven't heard of any DRM implementation
39:03
involving TPMs. I've said that these are slow, the discrete ones. You can use the firmware TPM if you want, if you trust Intel M.E. So you can trust it in either Intel or Infinium, your choice. Something which kind of was really annoying was the first stages
39:20
where we got our TPM and we just thought that these are standardized. So you might notice that in recent motherboards, I think this has been the case for years, pretty much each motherboard these days has a TPM header. So we thought that these are standardized, but in fact they are not.
39:42
We saw at least three different versions of the headers. So there was not just different pin count, but there was also a different pin pitch and I think the third or fourth motherboard that you found was good to accommodate the TPM which we got. So when you're buying a TPM,
40:01
make sure to double check or triple check if it will fit in your motherboard. The specification is pretty complex and hard to read, even to point out. It's pretty huge. It also involves a software layer with lots of terminologies. So I think this was one of the reasons why they did not have
40:21
such great adoption as they could have had. We also ran into some problems with available software for it. So for 2.0, not all options were supported by some common libraries. In particular, there's bus encryption. For example, we are using
40:40
the IBM TSS software library for communication with the TPM and it did not support bus encryption. So let's hope the state will get better. The fact that this bus is optional means that sometimes lacking support libraries
41:01
means that in most cases it is not used. So likely you might say that the TPM threat model physical attacks are out of scope, but if you have the bus encryption, then it's really hard to find the sniffer
41:21
because it's always good. Another thing is that I'll be talking about PCRs. Maybe it will make sense in a bit, but you have to make sure that you cannot reset these PCRs. Otherwise, you can kill the security of your network.
41:40
I've also said that you need to update your firmware and probably not a lot of people need to update it. Okay, so measure boot. This is something with this, I would say the biggest use case for the TPM. I've talked about secure boot before.
42:00
This is different. It's not really related, but it has similar purposes. I'll tell you how it differs. Measure boot is strictly involving TPM. This is a platform state or machine state. It is represented by the registers
42:20
which are called PCRs. These are the registers in TPM. There are something like 20 of them. They're called platform configuration registers. They just contain particular hashes like SHA-256 or SHA-512. The idea is that they can be extended.
42:42
You can't directly replace the PCR. You can't just put a value in the PCR. There's no operation like that. You can only do something which is called extending. You can see the equation for the extending. You have some specific value in the PCR.
43:00
You can read it. TPM will show it to you. If you want to extend this PCR with some new hash for new values, you supply it and the operation which is done is concatenation of the old one and the data to extend. Then the whole thing is hashed the PCR by the TPM. This is done by the TPM,
43:21
not by itself. The idea is that these are cryptographic hashes, so one-way functions. You cannot reverse this process. If you have a first stable loader, a next stable loader, a UEFI loader, at each stage, the specific image hashes
43:42
the next one to be loaded before loading it and puts this hash in the PCR recording state. Then the next one does the same, the next one does the same, but it's being stored in the same PCR. You cannot reverse this process and the sequence also matters.
44:05
Again, very similar purpose as in the case of secure boot. It's very important that you cannot reset the PCR. Usually the PCRs are reset to zero if the machine itself is reset by a CPI.
44:25
If the PCRs are not reset, if the second stage was loaded at the same, and the de-attacker takes execution, then you will not be able to make it so that there are specific hashes in this PCR.
44:41
You cannot replace it. You cannot extend anything, but they will not be able to extend it in such a way that the result will be what they want to be. It makes sense when I tell you how you can use these PCRs for locking different objects.
45:01
As I said, you're doing measurements when you're booting for each piece of firmware and also things like configuration and environmental variables and so on. The idea is that it's not the difference between secure boot and this is that this is just measuring. This is passive. If you're measuring, you're putting the hashes in the TPM
45:21
and you're continuing, so you're not preventing further execution. By the time you get to the OS, when you're in the OS, the PCRs are there in the TPM. You can read it and you can decide whether you're trusting the state or not. You remember what is the good value of the PCR.
45:41
If it's incorrect, you maybe stop execution. It can be different. As you wish, it's just information that the system is not trusted. You can do what you want with it, but you get up to the OS.
46:00
There will be no enforcement. If you have an object in the TPM like a key for encryption or any kind of secret, you can lock it to a specific state of the PCRs. There are different PCRs, so you can select which ones will be valid or not.
46:21
If you lock it to a specific state of the PCR, the TPM will only disclose this object in the PCR's manner. Again, if there's any change in any of the images previously, the headers will be completely different and the attack will not be able to reverse their own hash,
46:40
unless they are able to reset and go from zero. This is problematic in the sense that if you have this object and you see the particular state of the PCRs in the TPM, and you update any of the framework, any part,
47:01
then you will lose access to this object. The PCRs will be different. Your platform state is different. The TPM will not give you the key. Before you do any update, you have to unseal it, set a different PCR for the new state of the platform, and seal it again.
47:20
This is quite problematic, so it's really important to select the PCRs you are using correctly for a particular use case. Maybe you're not including the PCRs that are frequently changing. So that's the tricky part.
47:41
Again, this is how a measured boot flow looks like. We have up to 20 PCRs. Usually the lower ones are from the software that was executed earlier. So with trust for measurements, the first software is mouse, hashes the next state firmware, extends the PCR,
48:03
and the firmware does the same with the boot doubler, and then you end up with some kind of hash. Basically it's rolling hash into the PCRs. You can also, it's not just for booting. You can also, when you're in the US, you can hash some kind of configuration and also
48:20
lock secrets to that. So it's quite flexible. Apart from these PCR measurements, there's also an event lock which is created. I think it only concerns the UAFI. So it's just a list of objects which were hashed
48:40
and it also has different events for each object. So later on, when you're in the US, you can read this event lock, read the PCRs from the TPM, and replay all these extent operations like in software based on this equation that I showed you earlier, and you confirm whether it's authentic or not,
49:01
whether it's a match or not. Again, the TPM can sign those PCR values so the remote site can be assured that the platform state is such and such. The TPM obviously signs itself so it cannot be spoofed.
49:25
So we're thinking about whether we want any other features, the ones that are already working with UAFI and the loader, and we are quite satisfied with how it works now. So UAFI measures every binary which it runs,
49:42
and the loader.efi is an EFI binary, so it will be two different measurements. So it already works out of the box. However, previously, it cannot extend PCRs, so there's no support for that. Something that can be done
50:01
to improve this scheme is the loader could also measure the kernel and modules, but then if you update the kernel often, then everything you're locking is sealed. Okay, so now onto the IP set part.
50:24
Strongswan is an open source IP set implementation which our customer was using. And when the tunnels are established, the Internet Key Exchange protocol is used for initial authorization. So you can use either
50:40
pre-chaired keys which are available on both sides, like in TLS, or in certificates. We were using certificates, so we needed to be able to sign these certificates. Traditionally, we had private key in the file
51:00
on disk, and it could be in memory as well. So the idea is to use TPM so it has this embedded private key which never goes to software and the CPU will sign these certificates for us. So if you're signing a request, the TPM signs it and
51:21
just sends you the result about showing you the key. What you need to use that is this TPM driver we created, the software, the library layer called IBM TSS. There's also an Intel one. There are basically two versions. The Intel one is the most functional, has the biggest support,
51:40
but it was difficult to run it on FreeBSD because it has some dependencies. So we went with IBM TSS which is open source. You can download it on source support. And it does all the talking. It does all the protocol handling for the TPM. I think that's one idea was needed to make it build properly on PBSD.
52:02
The Intel one was more complicated. In fact, it's not yet been merged in the repository. Also, strong signing is somewhat different because it was primarily used with Intel, the TSS. So we have pull requests
52:22
on strong sign so that it works with IBM. That's how we can use it with PBSD. I talked about how the TPM signs the certificates. You can also use a passphrase as an additional layer of protection.
52:41
So it's either starting near text which is maybe not ideal in the strong sign configuration or it can be prompted for. Fair in mind that this is of course much slower if you're using a discrete implementation of the TPM. It takes something like 0.15 seconds to sign
53:00
with an RSA2K key which if you're establishing a lot of tunnels per second might be a problem. You might want to use the firmware one then or some other technology. This is how it looks in the strong sign configuration file.
53:20
It's called basically TPM objects are identified by these handles. So if you want to configure a strong sign to use the TPM and by the way the plugin for the TPM is already there in strong sign. We didn't have to write it so the support was already there. So we put the handle which we're going to use
53:41
for a specific tunnel and you put in an optional password if you want to use it or not. This way your key will not be ever available to the strong sign or any part of your system.
54:04
I think that's about it. There are lots of other uses for TPMs and I would say that for this comparison PCR state, and things like signing things for PPG or for APC, these are the most common ones.
54:21
So I think there's almost no reason not to use one because they're just so cheap and so useful. So yeah, this is pretty much what I have to say. There's a lot more you can do with TPMs. For this project,
54:41
for this presentation, so I'll put it up on the website of the conference. Some acknowledgements. Stormfield were the initiators of the project and the sponsor of the entire research that we did in the entire work. Also thanks to Simon and Jennifer for their cooperation
55:01
about the common integration of our exit and our patches into the result being so all of this is available and you can use it if you have any questions. Please ask us. We also update the pages if there's any need.
55:21
So we can use either TPM as an RNG, TPM just in general, very exact if you want it as an option and all the other things I talked about. So yeah, that's about it. Do you have any questions? Yes. Sorry, I'm sorry. So the load currently
55:41
keeps the CDO, VCR, everything in the patches. Unfortunately right now it's everything in the patches and in our implementation that can lead to the order in which it ends up really loaded on files and so on and so forth. But we think so that it only updates that CDO, VCR,
56:01
or the modules and other things that aren't cached then you end up having maybe a much more deterministic order. So you've got a better chance. So that ends up being exported to the kernel or userland. So you could actually log an RC script and update the VCR register using the name's kernel tool
56:21
rather than a bit more. Yeah, so as I said up to this point we were just, so far we were happy with extending the PCRs before the kernel. So CDFI does it with the loader and we didn't want to extend it further. But yeah, what you're saying would be an improvement.
56:44
Any other questions? Sure, we have two questions. One is the PCRs are used to store the results of the measured root process but you also said that the PCRs are only shared by hardware reset.
57:04
Or resets in some clear contents of the TPM operation. So usually on the platform I think the TPM reset which you have to do in order to clear the PCRs is combined with the ACPI reset
57:20
of the entire machine. So there shouldn't be, this is actually, there was an attack, I linked to it in the white paper where somebody found a way to only reset the TPM and the whole machine is being reset. And then the attacker can just, when the values are zero they can supply their own pathways.
57:41
So that breaks security. So that hardware reset is more multi-frequent? Yes. The only question is, the PCRs, there's a limited number of PCRs obviously and is there actually a total time period for which PCR you can use?
58:01
Yeah, you can use all of them or you can supply a bit mask of which PCRs you want to use for locking a specific object. So one object can be locked to a PCRI0123 or also 7 and the other object to different ones. But we have good environments now where all the pieces of code executed during the major good process
58:20
are written by the same person much less even the same organization. How do you coordinate that? Yes, I did mention that but it's actually kind of standardized by the TPM spec. I didn't put it up on the slide but it's kind of standardized in terms of these bootloaders
58:42
and this PCR and these are just for custom use by the US and so on and so forth. So it is standardized. Okay, so if I'm writing an operating system bootloader and there's a set that are basically reserved for the PC.
59:00
You said that to unlock when it goes to the down you have to provide the owner password? Yes, this password which is not used for most of the operations. It is the first thing which is set up when you provision the TPM. But could you just start to hammer that password
59:21
instead of the... The idea is that the owner password by the way, a fun fact when Microsoft finds a TPM like when Windows finds a TPM it starts to provision it the ownership of it that's what it's called
59:41
it sets up its own owner password I think it generates a random string it sets it up with the TPM and then forgets it never gives it to you. I guess they didn't want people to just write it down in a piece of paper or something it says you're supposed to...
01:00:00
Take this on a password, just don't want to store it somewhere safe, never use it again, only when you enter a lockdown or in some other situation where you need to own a password. Normally you don't use this password for anything else. I think again, when you're supplying the password, there's a separate mechanism, anti-hammering mechanism that I don't remember exactly.
01:00:25
Are there take-overship tools for VSD for 2.0? So you're using the IBM TSS, which has a toolkit for all the operations, pretty much all the operations, the TPMs to the take-ownership, that's another, it's one of the calls to the TPM, which we're using the TSS for, that's how we're using it with IBM TSS.
01:00:44
Okay. Okay, if there are no other questions, thank you all for coming.