Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Empfohlen
Empfohlen (20)
Locking Down the Endpoint with Measured Boot and UEFI
- 2. Introduction • What is UEFI? • What is a TPM? • What is “secure boot”? • What is “measured boot”? • What is “remote attestation”?
- 3. Hardware Landscape • BYOD • Capability standards • Phones • Tablets • PCs
- 4. UEFI secure boot • Usually can be disabled/modified by user o Behavior varies by implementation o Complicated, even for power users • But not on Windows 8 ARM. Options: o Buy a $99 signing certificate from VeriSign o Use a different ARM platform o Use x86
- 5. Measured Boot + Remote Attestation
- 6. What is measured boot? TPM BIOS Boot Loader Kernel Early Drivers Hash of next item(s) Boot Log [PCR data] [AIK pub] [Signature]
- 7. What is remote attestation? Client Device TPM Signed Boot Log Attestation Server some token…
- 8. DEMO • Measured Boot Tool (http://mbt.codeplex.com/) • Part 1: What’s in the boot log?
- 10. DEMO • Measured Boot Tool (http://mbt.codeplex.com/) • Part 2: How do you do remote attestation?
- 11. Data Flows C: Get AIK creation nonce S: Nonce C: Get challenge (EK pub, AIK pub) S: Challenge C: Get attestation nonce S: Nonce C: Signed boot log S: Token Client Device Attestation Service
- 12. DEMO Sample application #1: reduce fraud in mobile/consumer scenarios
- 13. Cloud Services Demand ID • Enterprise: BYOD • Consumer Targeted advertising eCommerce, mobile banking, etc. • But most user IDs are static & cached on device That only works for low-value purchases How to improve ID for high-value purchases?
- 14. Low Friction Authentication • Each additional screen requiring user input Slows down the process while user reorients Causes more users to abandon the web site • In contrast, Progressive Authentication: Let users investigate a site using just cookies Defers questions until information is needed Reduces user drop out from frustration
- 15. Splash Screen • The screen a user sees when app launched • With similar data in the launch tile
- 16. User Sign in • User name can be taken from cookie • But account details are hidden until the user enters a password
- 17. Enrollment - 1 • The first time the app is used the user must active the app • When this button is pressed an SMS message is sent to the phone # on file
- 18. Enrollment - 2 • After the user gets the pin from the SMS message, it is entered • After this the user proceeds as with a normal sign-in procedure
- 19. After Sign-in • The user sees all account information
- 20. User tries to move money • When user goes to move $ out of account • The health of the device is checked
- 21. Remediation Needed • If the device is not healthy enough to allow money transfer • The user is directed to a site to fix the problem
- 22. DEMO Sample application #2: Protect your data
- 23. Policy-Enforced File Access • BYOD • Download sensitive files from document repository • Leave laptop in back of taxi
- 24. Device AuthZ for SharePoint
- 25. Device AuthZ for SharePoint
- 26. Device AuthZ for SharePoint
- 27. Device AuthZ for SharePoint
- 28. Device AuthZ for SharePoint (SAML) Web Browser Client Agent Health Service Client Data Repository Custom Attribute Store ADFS SharePoint 5 4 6 2 3 Registration Portal 1
- 29. Device AuthZ for SharePoint (PKI) Web Browser Client Agent Registration Authority Client Certificate Authority SharePoint 2 3 4 Registration Portal 1
- 30. Weaknesses • Firmware & boot binary whitelist maintenance • What about user mode? • Integrity of the TPM in SOC architecture • UEFI: complex codebase, evolving rapidly
- 31. TPM Platform Attestation – DFD
- 32. Conclusion • Likelihood of mainstream adoption? • What the consumerization trend means for hackers • Opportunities in this space
- 33. Questions? dan@jwsecure.com 206-683-6551 @JWSdan JW Secure provides custom security software development services.
Hinweis der Redaktion
- UEFI is the Unified Extensible Firmware Interface. For the purpose of this discussion, UEFI is a programmable boot environment that is gradually replacing old-school BIOS.TPM stands for Trusted Platform Module, a crypto processor typically implemented either as a tamper-resistant motherboard chip or as part of a secure execution environment in system on a chip firmware.Secure boot is a feature of UEFI by which OEMs can control what boot images can be executed. Typically, secure boot includes support for both whitelisting and blacklisting of code signing keys as well as of boot loader binaries.Measured boot is a boot loader and operating system kernel feature that uses the TPM to keep a record of early-boot components as they load.Remote attestation is another TPM based feature, allowing a measured boot log to be evaluated by a remote server and for trust and policy decisions to be made based on the contents of that log.
- Support for UEFI and TPM is spotty in legacy hardware, but it is growing, particularly on the PC side. Support for these technologies in mobile devices is still difficult to predict. Microsoft is pushing them, for example. Support for TPM in Windows 8 Pro devices is required by their hardware standard. But the jury is still out on whether software developers and startups can count on having these capabilities in the top-tier mobile platforms, for example.Nevertheless, given the bring your own device trend in enterprise IT, buyers are pushing for new capabilities that allow them to protect sensitive data while lowering hardware support costs.
- The big drama about Windows 8 and UEFI secure boot was when Microsoft stated that OEMs must configure secure boot as mandatory on ARM devices and that it cannot be disabled by users. However, the major Linux distributions provide signed boot loaders. Unless you plan on doing custom kernel work, you’re good to go. Otherwise, you’ll have to evaluate the options.
- In review, UEFI secure boot allows you to control at the firmware level what boot loaders are allowed. But what if we want to make more nuanced policy decisions, and extend them higher up the boot stack? Even better, what if we want to make authorization decisions within a line of business service based on boot measurements made on the client? What level of trust can the service place in those measurements?
- With measured boot, starting with the BIOS, before each component in the boot chain is loaded, the previous component computes its hash on disk and stores that hash value in the TPM. Data is stored in the TPM Platform Configuration Registers, or PCRs.After boot, a boot log can be retrieved from the TPM. The log includes the boot image hashes, code-signing information, and other boot metadata. Importantly, the TPM can also sign the log with a special-purpose Attestation Identity Key, or AIK.
- Remote attestation builds on measured boot. Remote attestation works like this. The client device, shown on the left-hand side of the diagram here, gets turned on and runs through the TPM-based measured boot procedure. Then, some client application that wants to perform remote attestation retrieves the signed boot log from the TPM and sends it to a remote server for verificationThe remote server verifies that it trusts the TPM key that signed the log, that the log hasn’t been tampered with, and that it trusts each of the boot binaries in the logThen, in a typical line of business scenario, the remote server sends some sort of token back to the client indicating the result of the boot log checkFinally, the client presents the token to the line of business service and the service makes authorization decisions based on the attestation tokenThere’s a fair amount of complexity here, and plenty of things that can go wrong. But some demonstrations will at least help to make this more concrete.
- My open-source Measured Boot Tool allows you to view Trusted Platform Module (TPM) boot data, experiment with measured boot, and even identify risks such as unsigned early-boot drivers. The tool implements the following:Establish a attestation key, based on a simulated database of trusted TPMs, using the Endorsement Key, or permanent encryption key stored on the TPMProduce a boot log signed by the new keyFormat the boot data for human consumptionFlag risks such as unsigned early-boot drivers
- This is sample console output from Measured Boot Tool. I ran it on my HP laptop running Windows 8. A couple of things to note in the output of the tool:Boot log metadata: namely, that disk encryption is enabled with a hardware-based key, and that the latest boot integrity features of the boot loader have been enabled.There’s a long list of early-boot drivers. This is a significant attack surface.
- In introducing Measured Boot Tool, I mentioned that it creates a new trusted attestation key on the TPM before extracting and parsing the boot log. Creating the attestation key, and establishing that the TPM is trusted, is the foundation of remote attestation, because without it a remote server can’t trust the boot log data that it receives from the client device.Measured Boot Tool demonstrates the procedure of establishing remote trust and simulates the data exchange between a measured boot client and an attestation server.
- This diagram shows the client and server messages that can be used in TPM remote attestation. In other words, this is what the client device can do in order to transmit a boot log to an attestation service in a trusted way.First, the client requests an attestation nonce. This sequence assumes that the server already has a database of trusted TPM endorsement key issuers. A nonce is used to ensure that a new attestation key is created and that it’s truly stored on the TPM. Next the client requests an encrypted challenge. The request includes some binding information from the TPM regarding the new AIK. What the client receives from the server is a AIK certificate with an encrypted signature. If the client can decrypt the signature and use the AIK certificate for the next attestation, then the server knows that the AIK was generated after the nonce was requested and that the AIK is bound to the same TPM as the EK. This step establishes the trusted attestation key for this boot log exchange.Then the client requests an attestation nonce. This nonce is used to ensure that a previous boot log isn’t being replayed.Finally, the client uses the agreed attestation key and attestation nonce to produce the signed boot log that is sent to the server for verification.Again, there’s some complexity here, including cryptographic steps that are easy to get wrong. Nevertheless, remote attestation gives us a powerful tool to ensure that compromised client devices can’t access sensitive network resources.
- Back to the mobile banking example scenario, let’s look at the current state of affairs for performing security checks on remote devices, and consider the gaps.
- The question is how can we use technologies such as remote attestation to raise the security bar in the consumer-class device scenarios, in a standards-based way, without imposing too much of a burden on the user?
- In addition, we also want to demonstrate that devices can be authenticated using hardware-based trust in a way that is seamless to the user. This reduces support cost.
- This demonstration starts with a mobile banking application. In this screen, notice that the bank is able to present the user with certain information before there’s been any sign-in experience. This is an important consideration in app design, because it helps to make the app feel more natural and useful.
- After the user clicks the Sign In button, they’re asked for their existing logon information for online checking.
- Since this is the first time the app has run, we want to bind the device to the user. For this demo, we assume that the bank already has the user’s mobile phone number from the initial in-person proofing when the account was setup.What we’d like to be able to do is bind the device using a known TPM endorsement key, as shown in the remote attestation flow, previously. As yet, few smartphones expose TPM capabilities to app devs. Still, there’s an opportunity here to raise the bar, for example using a unique device identifier, the SIM chip, or even an ARM TrustZone application.
- In order to bind the device to the user, the bank sends a text message with a one-time PIN. The user enters that PIN along with the existing username and password for the first-time device setup. Solutions such as Microsoft PhoneFactor offer similar capabilities.
- Now the user has read-only access to the checking account. The account balance information is visible.
- However, in order to transfer money, an additional security check must be performed.
- Namely, information about the device is gathered behind the scenes and sent to the backend in the form of an authorization token. In this version of the demo, the device firmware is out of date. Therefore, the banking web service doesn’t trust that the device is operating correctly on behalf of the user, so the risky transaction – funds transfer – is blocked.The challenge is that without the hardware root of trust provided by a technology such as TPM remote attestation, the banking web service can’t trust that the client application, operating system, and the device itself are really acting on behalf of the user and haven’t been compromised.
- Recall that I mentioned earlier that the measured boot log includes additional boot metadata beyond just the list of early-boot drivers. Namely, the log shows whether disk encryption is in use.
- A second sample application that really motivates the use of remote attestation is data access by trusted insiders. In this case, we want to ensure that only users with trusted client machines and encrypted disks can download sensitive files from a document repository. By enforcing disk encryption and hardware identity, we help to decrease the chance that data can be recovered from a lost or stolen device.
- This demo uses remote attestation-based device authorization to restrict access to SharePoint. Users can’t access the document repository unless their device has:No root kits, andTPM BitLocker with a boot PINThe scenario starts with a new device that the user just picked up from Best Buy. The user is working on the road so they need to get to SharePoint. If the user hasn’t already downloaded the device authorization Client Agent and registered the device, they get a friendly reminder, along with a convenient link, that they need to do so. This is a custom error page in SharePoint, demonstrating that a device that hasn’t successfully completed TPM remote attestation can’t access the document repository.This demonstration shows static password-based user authentication, but client certificates or one-time passwords would be a more secure alternative.
- The portal page presents users with the appropriate Client Agent download link for their device type.
- Finally, a trusted, authenticated user, with a healthy, registered device, is allowed access to the document repository. After initial registration of the device, we expect the user sign-in procedure to be seamless. Rootkits and other unauthorized boot-level changes should be uncommon events, as should be leaving a device full of sensitive documents in the back of a taxi. Nevertheless, this approach mitigates both of those risks.IT decision makers want high-security and high-assurance, but they can’t afford to drive up support costs, or to cause false-negatives that lock out authorized users and devices. The goal of any device authorization system is to be invisible to the user. This is achievable with the usual IT best-practices: pilot testing, measuring user satisfaction, and maintaining a feedback loop for continuous improvement.
- Speaking of measuring, authorization systems can be very interesting from a metrics and trends standpoint. This screen shows a simple dashboard that goes red or green based on whether non-compliant, or unhealthy, client devices are currently registered on the network. In the case of remote attestation data, non-compliance could mean that one of your trusted users has a device with a rootkit. Operationally, it is expected that the data access rules will block non-compliant devices. For example, that was the case in the secure SharePoint repository example that I just showed. But nevertheless auditing is important to ensure that high-assurance systems are behaving as expected.Interesting auditing queries include: how many people are using the system, and what LOB apps are they trying to access? Usage data is important for justifying IT spend. Also, what devices are non-compliant and who is using them? When you can demonstrate that you’ve kept sensitive data off of a rooted device, or mitigated a spear phishing attack, that’s a win for IT security.
- We’ve seen the front-end and reporting capabilities of an example SharePoint deployment using device authorization based on TPM remote attestation. Let’s switch gears and look at the architecture. The goal is to expose platform attestation in a way that readily integrates with existing LOB apps. I’ll look at two approaches – one based on SAML and one based on PKI. This diagram shows the SAML version. Let’s walk through the dataflow: The user opens the web browser on a new Windows 8 host and navigates to the registration portal. See arrow #1.The portal requires a SAML token, which the client doesn’t yet have, and redirects to ADFS. See arrow #2.The user authenticates to ADFS During the authentication request, the health claims Custom Attribute Store extension to ADFS looks up the user and determines that the user has not yet registered the device. See arrows #3 and #4. Thus, the user is asked to install the Client Agent.Once the Client Agent is installed, it performs remote attestation with the Health Service. See arrow #5.Next, the user attempts to open the document repository. The data contained therein is considered to be business sensitive. See arrow #6.The document repository also requires a SAML token. The browser is again redirected to ADFS.See arrow #2 again.ADFS verifies the user’s identity and device health data. Assuming that the client agent reported the device as healthy, and the user credential is valid, the user is redirected back to the document repository and may now access the sensitive data. That’s the SAML approach. But…
- What if, instead of relying on a token service or federation, we want to leverage an existing PKI? This approach arguably offers higher security, but at the expense of usability. I’ll come back to that in a second. First, let’s look at the data flow: The user opens the web browser on a new host,navigates to the registration portal, and installs the Client Agent. See arrow #1.Once the Client Agent is installed, it initiates remote attestation with the Registration Authority. See arrow #2.The RA verifies that the attested log is valid and that it comes from a trusted TPM. After that, the RA requests a client authentication certificate on behalf of the user. See arrow #3.The private key of the new device certificate is special in two ways:It is encrypted in such a way that only that TPM can decrypt and use itThe private key is measurement-bound. That is, next time the boot measurements for that device change, the key becomes invalid, and the user will need to request a new client auth certificate and keyThe final step in the data flow is that the user navigates to the document repository and uses TLS client certificate authentication to login. Why is this approach potentially more secure than the web token based implementation? Because in this case the user credential is tightly bound to the device boot measurements. When the measurements change, the client certificate private key is no longer usable.What is the usability tradeoff? Imagine every user shows up in the morning and wakes their computers out of hibernate. Since hibernate increments the TPM boot counter, that changes the boot measurements, and invalidates the client certificate. Thus, every device is going to be hitting the RA and the CA. Plus, every user is going to be waiting a minute or so for remote attestation to complete before they can access SharePoint. This could be a source of frustration.
- That brings us to a broader discussion of the challenges in integrating these capabilities. UEFI secure boot, TPM measured boot, and remote attestationare important endpoint security technologies, but there are weaknesses. At a high-level, there are two important things to keep in mind:First, we’re still generally assuming that the user is an ally – for example, that the user won’t go out of his or her way to physically compromise the device. Second, as I’ve demonstrated, there’s complexity here, and in software increased complexity means increased bugsWith those two things in mind, this slide lists some other weaknesses to be aware of.[Describe]It’s important to research and mitigate the known weaknesses inherent to any technology under consideration. But it’s equally important to do a brief formal analysis of the risks present in a system. And, after all, this is the SDL conference. How do we document risks and mitigations in SDL?(Threat Model)What’s the first step of a Threat Model?
- A Data Flow DiagramThis is the data flow diagram that JW Secure developed for our own commercial TPM platform attestation solution called StrongNet. This was originally delivered to DARPA, the research arm of the US Dept. of Defense, for a project funded by their Cyber Fast Track program. The DARPA project .was called BIOS Integrity Measurements Heuristics Tool, or BHT.The first step in creating a useful DFD is to make a straw man architecture like this one and the others I just showed for the SharePoint device authorization demonstration. Separate the various system components into boxes such that all of the communication paths, i.e. data flows, can be represented by arrows. For example, note in this diagram where the Client Agent retrieves the signed attestation data from the local TPM, and then where the Client Agent sends that attested boot log to the Server.The next step is to mark trust boundaries. For example, there are two particularly noteworthy trust boundaries in a TPM remote attestation system. The first is on the far right, where the TPM chips or firmware are received from the manufacturer. The second is on the far left where attestation data leaves the physical client device and must be evaluated remotely.Then, look at where data flows cross trust boundaries. That’s where you’ll find the highest risk and the need to apply mitigations. For example, on the right, how do we mitigate the risk that the TPM firmware we receive from the manufacturer is already rooted? And on the left, how do we mitigate the risk that the platform attestation service is receiving a complex data structure, the boot log, from untrusted client devices? Finally, document your risks and mitigations: that becomes your Threat Model. You’ll find that by identifying and prioritizing risk, and applying best-practice mitigations such as input validation, authentication, authorization, and auditing, you can field a system that is cost effective, useful, and sufficiently secure. We have found that to be the case with TPM remote attestation.
- Looking forward, from my perspective as a security software integrator, there are two questions:First, Windows 8 has excellent developer support for the technologies we’ve been discussing, but will their particular consumer hardware strategy be successful?Second, will similar features become more widely supported by the top smartphones and tablets?Either way, as I’ve demonstrated, capabilities such as measured boot are already present on most enterprise class PCs. So don’t be like James Bond’s Swiss banker. Secure your data with endpoint encryption policy, protect your cloud resources with device authorization, …