Tuesday, October 22nd 2019

AMD Announces Integration With Microsoft's Secured-Core PC Initiative

In today's world, computer security is becoming very important due the exponential increase in malware and ransomware attacks. Various studies have shown that a single malicious attack can cost companies millions of dollars and can require significant recovery time. With the growth of employees working remotely and connected to a network considered less secure than traditional corporate network, employee's computer systems can be perceived as a weak security link and a risk to overall security of the company. Operating System (OS) and independent hardware vendors (IHV) are investing in security technologies which will make computers more resilient to cyberattacks.
Microsoft recently announced their Secured-core PC initiative which relies on a combined effort from OEM partners, silicon vendors and themselves to provide deeply integrated hardware, firmware and software for enhanced device security. As a leading silicon provider to the PC market, AMD will be a key partner in this effort with upcoming processors that are Secured-core PC compatible.

In a computer system, low level firmware and the boot loader are initially executed to configure the system. Then ownership of the system is handed over to the operating system whose responsibility is to manage the resources and to protect the integrity of the system.

In today's world, cyberattacks are becoming increasingly sophisticated, with threats targeting low level firmware becoming more prominent. With this changing paradigm in security threats, there is strong need to provide end customers with an integrated hardware and software solution which offer comprehensive security to the system.
This is where the Microsoft Secured-core PC initiative comes into the picture. A Secured-core PC enables you to boot securely, protect your device from firmware vulnerabilities, shield the operating system from attacks and prevent unauthorized access to devices and data with advanced access controls and authentication systems.

AMD plays a vital role in enabling Secure-Core PC as AMD's hardware security features and associated software helps safeguard low level firmware attacks. Before we explain how AMD is enabling Secured-Core PC in next gen AMD Ryzen products, let's first explain some security features and capabilities of AMD products.

SKINIT
The SKINIT instruction helps create a "root of trust" starting with an initially untrusted operating mode. SKINIT reinitializes the processor to establish a secure execution environment for a software component called the secure loader (SL) and starts execution of the SL in a way to help prevent tampering SKINIT extends the hardware-based root of trust to the secure loader.

Secure Loader (SL)
The AMD Secure Loader (SL) is responsible for validating the platform configuration by interrogating the hardware and requesting configuration information from the DRTM Service.

AMD Secure Processor (ASP)
AMD Secure Processor is dedicated hardware available in each SOC which helps enable secure boot up from BIOS level into the Trusted Execution Environment (TEE). Trusted applications can leverage industry-standard APIs to take advantage of the TEE's secure execution environment.

AMD-V with GMET
AMD-V is set of hardware extensions to enable virtualization on AMD platforms. Guest Mode Execute Trap (GMET) is a silicon performance acceleration feature added in next gen Ryzen which enables hypervisor to efficiently handle code integrity check and help protect against malware.

Now let's understand the basic concept of firmware protection in a Secured-core PC. The firmware and bootloader can load freely with the assumption that these are unprotected code and knowing that shortly after launch the system will transition into a trusted state with the hardware forcing low level firmware down a well-known and measured code path. This means that the firmware component is authenticated & measured by the security block on AMD silicon and the measurement is securely stored in TPM for further usage by operating systems including verification and attestation. At any point of time after system has booted into OS, the operating system can request AMD security block to remeasure and compare with old values before executing with further operations. This way the OS can help ensure integrity of the system from boot to run time.
The firmware protection flow described above is handled by AMD Dynamic Root of Trust Measurement (DRTM) Service Block and is made up of SKINIT CPU instruction, ASP and the AMD Secure Loader (SL). This block is responsible for creating and maintain a chain of trust between components by performing the following functions:

Measure and authenticate firmware and bootloader
To gather the following system configuration for the OS which will in turn validate them against its security requirements and store information for future verification.
  • Physical memory map
  • PCI configuration space location
  • Local APIC configuration
  • I/O APIC configuration
  • IOMMU configuration / TMR Configuration
  • Power management configuration
Whilst the above methods help in safeguarding firmware, there is still an attack surface that needs to be protected, the System Management Mode (SMM). SMM is a special-purpose CPU mode in x86 microcontrollers that handles power management, hardware configuration, thermal monitoring, and anything else the manufacturer deems useful. Whenever one of these system operations is requested, an interrupt (SMI) is invoked at runtime which executes SMM code installed by the BIOS. SMM code executes in the highest privilege level and is invisible to the OS. Due to this, it becomes attractive target for malicious activity and can be potentially used access hypervisor memory and change the hypervisor.

Since the SMI handler is typically provided by a developer different then the operating system and SMM handler code running at a higher privilege has access to OS/Hypervisor Memory & Resources. Exploitable vulnerabilities in SMM code leads to compromise of Windows OS/HV & Virtualization Based Security (VBS). To help isolate SMM, AMD introduces a security module called AMD SMM Supervisor that executes immediately before control is transferred to the SMI handler after an SMI has occurred. AMD SMM Supervisor resides in AMD DRTM service block and the purpose of AMD SMM Supervisor is to:
  • Block SMM from being able to modify Hypervisor or OS memory. An exception is a small coordinate communication buffer between the two.
  • Prevent SMM from introducing new SMM code at run time
  • Block SMM from accessing DMA, I/O, or registers that can compromise the Hypervisor or OS
To summarize, AMD will continue to innovate and push boundaries of security in hardware, whether it is DRTM service block to help protect integrity of the system, the use of Transparent Secure Memory Encryption (TSME) to help protect data or Control-flow Enforcement technology (CET) to help prevent against Return Oriented Programming (ROP) attacks. Microsoft is a key partner for AMD and as part of this relationship there is a joint commitment with the Secured-core PC initiative to improve security within software and hardware to offer a more comprehensive security solution to customers. Sources: Microsoft Secured-Core, AMD
Add your own comment

15 Comments on AMD Announces Integration With Microsoft's Secured-Core PC Initiative

#1
R-T-B
Security "hardware" is a bad joke. I can't think of one place it's ever been helpful, and it often ends up with exploitable security holes that are hard to fix because it's hardware.

Also
The AMD Secure Loader (SL) is responsible for validating the platform configuration by interrogating the hardware and requesting configuration information from the DRTM Service.
Say bye bye to any and all bios mods as well...

#ThanksAMD
Posted on Reply
#2
trparky
Truth be told @R-T-B, those opportunities that you say open the way for BIOS mods are the same very holes used by the bad guys to do harm. Security has always been a compromise between usability, customization, and the protection of the computing environment. And you know what the definition of a compromise is, right? It's a solution to a problem that nobody likes.
Posted on Reply
#3
R-T-B
trparky
Truth be told @R-T-B, those opportunities that you say open the way for BIOS mods are the same very holes used by the bad guys to do harm.
Not at all. Hijacking a security processor on the other hand, is a very hot topic of discussion.

Bios mods are done doing the bios flashing interface available on every motherboard. This is NOT a "security hole." What is disturbing is that they seem to think a simple bios hash will suffice and really do much of anything except prevent mods. History has shown us it won't.

This subsystem will end up another tool to use against the end user if badly infected, not vice versa. The only way to keep a machine safe is rather simple: Never allow nefarious code to run as admin. If it does, pray it doesn't have tools like this to lock you out, because given enough time and research, it WILL utiluze them.
Posted on Reply
#4
eidairaman1
The Exiled Airman
We need to go back to a physical jumper config for the bios to prevent firmware being overwritten by hacks, that should be on gpus too.
Posted on Reply
#5
Bones
eidairaman1
We need to go back to a physical jumper config for the bios to prevent firmware being overwritten by hacks, that should be on gpus too.
This.
Having everything secured via software alone isn't a good idea because software can be manipulated. Having it based more on a hardware level like a jumper or switch that has to be "on" to do a flash is more secure than basing it all on software alone for locking out the ability to flash or change something.

Speaking of things being controlled by software, It's like when you disable a device such as your Wi-Fi for example in the BIOS or OS - Is it "really" disabled or just not showing what it's really doing?
Posted on Reply
#6
candle_86
I agree a physical write only jumper for accessing the ROM chip. Make the system unbootable if the ROM is write enabled as a group policy item to prevent quick physical attacks as well. I'd also like to see a require bios password stored like in modern Enterprise systems that requires it be enabled and configured to block unauthorized access
Posted on Reply
#7
R-T-B
eidairaman1
We need to go back to a physical jumper config for the bios to prevent firmware being overwritten by hacks, that should be on gpus too.
You and me agree on this one.

I mean the chips already have a write protect pin. This isn't rocket science... So you want to mod your card/bios? Cool, pull the jumper. Done? Set it back.

I think we have terrified people of jumpers from back in the ISA era, but seriously, there's nothing bad about them. They work.
Posted on Reply
#8
Easo
R-T-B
Security "hardware" is a bad joke. I can't think of one place it's ever been helpful, and it often ends up with exploitable security holes that are hard to fix because it's hardware.
TPM chip, used by tens of millions of PCs. Industry would disagree with you.
And EVERYTHING has bugs, so what, stop using it? :/
Posted on Reply
#9
R-T-B
Easo
TPM chip, used by tens of millions of PCs. Industry would disagree with you.
You mean the one that was hacked by some Russians in about 3 months?

Granted, they needed physical access. Today, not so much:

https://www.bleepingcomputer.com/news/security/researchers-detail-two-new-attacks-on-tpm-chips/

No, industry would not agree with me. They are pushing this garbage. Most industry EXPERTS are in unanimous agreement about how dumb that is though.

Easo
And EVERYTHING has bugs, so what, stop using it? :/
If it can take over your entire PC, yeah, kinda.
Posted on Reply
#10
Easo
R-T-B
You mean the one that was hacked by some Russians in about 3 months?

Granted, they needed physical access. Today, not so much:

https://www.bleepingcomputer.com/news/security/researchers-detail-two-new-attacks-on-tpm-chips/

No, industry would not agree with me. They are pushing this garbage. Most industry EXPERTS are in unanimous agreement about how dumb that is though.



If it can take over your entire PC, yeah, kinda.
As I said, everything has bugs and nothing is perfect. I think have seen the need to update TPM firmware only once in its existence. This garbage is awesome, because it allows to do nice things with, say, BitLocker, for example, and I have yet to see anyone actually break BitLocker.
You cannot get to the encryption keys, which is the most important thing, nor you can add funny stuff to the PC and and get it to boot OS, because TPM will block that, unless you have recovery keys.
Understand - you versus TPM and how much enterpises love it is a very... onesided battle.
Posted on Reply
#11
candle_86
Any Enterprise worth their salt would be using what's considered best practice for encryption. TPM + pin/password, it mitigates any TPM vulnarabilities and requires 2 items are compromised. The recovery key should only be stored in AD where it is encrypted and has tight access control.
Posted on Reply
#12
eidairaman1
The Exiled Airman
R-T-B
You and me agree on this one.

I mean the chips already have a write protect pin. This isn't rocket science... So you want to mod your card/bios? Cool, pull the jumper. Done? Set it back.

I think we have terrified people of jumpers from back in the ISA era, but seriously, there's nothing bad about them. They work.
I guess ive never been terrified about them because I had a P4 board that had a 2 type ram config.
Posted on Reply
#14
Easo
R-T-B
With local access, yes, you can:

https://medium.com/cyber-journal/new-attack-could-extract-bitlocker-encryption-keys-from-a-tpm-61475c311052



Of course it is. Only one side has money.
It "could", yet there are no real life cases. It is probably the most used full disk encryption system in Windows, which should make it more likely to be attacked, but it has not fallen as of yet. Sure, someday, but it is not yet here after more than a decade.
The other side has also huge experience across multitude of wildly different companies in every sphere imaginable. If that is good enough for military and multibillion companies, it should be good enough for you too. I am not even really sure why you are against it. Trusting software security is the same as trusting device firmware - it also is just a software.
Posted on Reply
#15
R-T-B
Easo
It "could", yet there are no real life cases.
Dude, there totally are. Heck, I've done it.

I've personally extracted keys from a Thinkpads T400s TPM module to reset a locked bios. It takes like, a computer with a serial port and two wires + a soldering iron.

That was years ago, too. It's only gotten worse and there have been no new TPM standards since 2.0 came out.

It's... not a mirracle device. There's a reason almost all modern PCs don't even bother with the module anymore, and have moved it instead into firmware: Because the modules are hackable. Heck, the standard itself is flawed in such a a way you don't even need to pop the lid on most computers, you just need access to a booted machine.

Start here and count:

https://en.wikipedia.org/wiki/Trusted_Platform_Module#Attacks

Linked the "Attacks" section for you.

Easo
It "could", yet there are no real life cases. It is probably the most used full disk encryption system in Windows, which should make it more likely to be attacked, but it has not fallen as of yet.
Bitlocker? LOL. Of course bitlocker itself hasn't been hacked, it is using friggin AES and that would break the universe online if someone hacked that. The US government (not Microsoft) spent a lot of money and did the heavy lifting there.

You know you can do that exact same thing though without the TPM and a passphrase? And then you can actually have it in your brain (or maybe in an automated envioronment, PXE boot script), which is arguably more difficult to hack/exploit?

I can however most assuredly assure you I can get the bitlocker AES private key out of ANY TPM if I have access to the system warm booted (I do not care if the system is locked, and I only need a half hour tops)... It's not used because it's a secure standard, it's used because it's easy, available, and pushed by the vendors.

The one thing I think TPMs are kinda decent at is hash validation. Which is a joke, because any CPU can do that in software now (most with a special instruction to speed it along).

I mean, I get the industry uses it. I was ordered to use hardware encrypted HDDs (Why do you think I have a bunch of Ultrastar's and Contellations?) at one of my old jobs. But... there are all bad ideas vs software encryption. Any time the key is stored somewhere on the device, it can be extracted with enough effort. Simple.

Remember, IT Security Consulting is kind of my field these days. I'm not talking out of my ass.

Are TPMs horrible devices? No. But should you count on them to do anything to protect you INSTEAD of a software encryption solution?

I guess that depends on how much it'll cost you if you get a breach, and how likely that is. Do your own cost evaluation.
Posted on Reply
Add your own comment