da Agency

Titan in depth: Security in plaintext

By Uday Savagaonkar, Technical Lead Manager, Nelly Porter, Senior Product Manager, Nadim Taha, Software Lead,
Benjamin Serebrin, Tech Lead and Neal Mueller, Product Marketing Lead

While there are no absolutes in computer security, we design, build and operate Google Cloud Platform (GCP) with the goal to protect customers’ code and data. We harden our architecture at multiple layers, with components that include Google-designed hardware, a Google-controlled firmware stack, Google-curated OS images, a Google-hardened hypervisor, as well as data center physical security and services.

Photograph of Titan inside Google’s purpose-built server

In this post, we provide details of the mechanisms of how we will establish a hardware root of trust using our custom chip, Titan.

First introduced at Google Cloud Next ’17, Titan is a secure, low-power microcontroller designed with Google hardware security requirements and scenarios in mind. Let’s take a look at how Titan works to ensure that a machine boots from a known good state using verifiable code, and establishes the hardware root of trust for cryptographic operations in our data centers.

Photograph of Urs Hölzle unveiling Titan at Google Cloud Next ’17 (YouTube)

Machine boot basics 
Machines in Google’s datacenters, as with most modern computers, have multiple components, including one or more CPUs, RAM, Baseboard Management Controller (BMC), NIC, boot firmware, boot firmware flash and persistent storage. Let’s review how these components interact to boot the machine:

The machine’s boot process starts when the BMC configuring the machine hardware lets the CPU come out of reset. 
The CPU then loads the basic firmware (Boot or UEFI) from the boot firmware flash, which performs further hardware/software configuration. 
Once the machine is sufficiently configured, the boot firmware accesses the “boot sector” on the machine’s persistent storage, and loads a special program called the “boot loader” into the system memory. 
The boot firmware then passes execution control to the boot loader, which loads the initial OS image from storage into system memory and passes execution control to the operating system. 

In our datacenters, we protect the boot process with secure boot. Our machines boot a known firmware/software stack, cryptographically verify this stack and then gain (or fail to gain) access to resources on our network based on the status of that verification. Titan integrates with this process and offers additional layers of protection.

As privileged software attacks increase and more research becomes available on rootkits, we have committed to delivering secure boot and hardware-based root of trust for machines that form our infrastructure and host our Google Cloud workloads.

Secure boot with Titan 
Typically, secure boot relies on a combination of an authenticated boot firmware and boot loader along with digitally signed boot files to provide its security guarantees. In addition, a secure element can provide private key storage and management. Titan not only meets these expectations, but goes above and beyond to provide two important additional security properties: remediation and first-instruction integrity. Trust can be re-established through remediation in the event that bugs in Titan firmware are found and patched, and first-instruction integrity allows us to identify the earliest code that runs on each machine’s startup cycle.

To achieve these security properties, Titan comprises several components: a secure application processor, a cryptographic co-processor, a hardware random number generator, a sophisticated key hierarchy, embedded static RAM (SRAM), embedded flash and a read-only memory block. Titan communicates with the main CPU via the Serial Peripheral Interface (SPI) bus, and interposes between the boot firmware flash of the first privileged component, e.g., the BMC or Platform Controller Hub (PCH), allowing Titan to observe every byte of boot firmware.

Titan’s application processor immediately executes code from its embedded read-only memory when its host machine is powered up. The fabrication process lays down immutable code, known as the boot ROM, that is trusted implicitly and validated at every chip reset. Titan runs a Memory Built-In Self-Test every time the chip boots to ensure that all memory (including ROM) has not been tampered with. The next step is to load Titan’s firmware. Even though this firmware is embedded in the on-chip flash, the Titan boot ROM does not trust it blindly. Instead, the boot ROM verifies Titan’s firmware using public key cryptography, and mixes the identity of this verified code into Titan’s key hierarchy. Then, the boot ROM loads the verified firmware.

Once Titan has booted its own firmware in a secure fashion, it will turn its attention to the host’s boot firmware flash, and verify its contents using public key cryptography. Titan can gate PCH/BMC access to the boot firmware flash until after it has verified the flash content, at which point it signals readiness to release the rest of the machine from reset. Holding the machine in reset while Titan cryptographically verifies the boot firmware provides us the first-instruction integrity property: we know what boot firmware and OS booted on our machine from the very first instruction. In fact, we even know which microcode patches may have been fetched before the boot firmware’s first instruction. Finally, the Google-verified boot firmware configures the machine and loads the boot loader, which subsequently verifies and loads the operating system.

Photograph of Titan up-close on a printed circuit board.

Cryptographic identity using Titan 
In addition to enabling secure boot, we’ve developed an end-to-end cryptographic identity system based on Titan that can act as the root of trust for varied cryptographic operations in our data centers. The Titan chip manufacturing process generates unique keying material for each chip, and securely stores this material—along with provenance information—into a registry database. The contents of this database are cryptographically protected using keys maintained in an offline quorum-based Titan Certification Authority (CA). Individual Titan chips can generate Certificate Signing Requests (CSRs) directed at the Titan CA, which—under the direction of a quorum of Titan identity administrators—can verify the authenticity of the CSRs using the information in the registry database before issuing identity certificates.

The Titan-based identity system not only verifies the provenance of the chips creating the CSRs, but also verifies the firmware running on the chips, as the code identity of the firmware is hashed into the on-chip key hierarchy. This property enables remediation and allows us to fix bugs in Titan firmware, and issue certificates that can only be wielded by patched Titan chips.

The Titan-based identity system enables back-end systems to securely provision secrets and keys to individual Titan-enabled machines, or jobs running on those machines. Titan is also able to chain and sign critical audit logs, making those logs tamper-evident. To offer tamper-evident logging capabilities, Titan cryptographically associates the log messages with successive values of a secure monotonic counter maintained by Titan, and signs these associations with its private key. This binding of log messages with secure monotonic counter values ensures that audit logs cannot be altered or deleted without detection, even by insiders with root access to the relevant machine.

Conclusion 
Our goal is to protect the boot process by securing it with a dedicated entity that is explicitly engineered to behave in an expected manner. Titan provides this root of trust by enabling verification of the system firmware and software components, and establishes a strong, hardware-rooted system identity. Google designed Titan’s hardware logic in-house to reduce the chances of hardware backdoors.

The Titan ecosystem ensures that production infrastructure boots securely using authorized and verifiable code.

In short:

Titan provides a hardware-based root of trust that establishes strong identity of a machine, with which we can make important security decisions and validate the “health” of the system. 
Titan offers integrity verification of firmware and software components. 
The system’s strong identity ensures that we’ll have a non-repudiable audit trail of any changes done to the system. Tamper-evident logging capabilities help identify actions performed by an insider with root access. 

For more information about how we harden our environment, visit the Google Cloud Platform Security page.

Quelle: Google Cloud Platform

da Agency

Accessing Guest RDP and SSH via Custom Buttons

First let’s talk about Remote Session vs Remote Console, they are often confused.
 

Remote Session – Provides the user a server session on the remote host. Multiple sessions can be established with same or different credentials.
Remote Console (Also known as Remote Control) – Provides the actual console screen to the user, still a session but the systems local session. Only one console session can exist. Any credentials with rights to log on locally can obtain the system session. (Default in Windows is Deny)

 

In CloudForms you will have full visibility of all Virtual Machines and Instances in the providers configured. The inventory for any of these objects will include the Hostnames configured. Given that the hostname is available, you can with any Remote Desktop Protocol (RDP) or Secure Shell (SSH) client make a connection.
 
Question : Can we make CloudForms call our client?
Answer : Yes, assuming your clients for RDP or SSH have an association scheme in the browser you are using to access CloudForms, normally the case.
 
The association scheme is the prefix to the address, normally known as the URI protocol. Example;
 

HTTP://…… – In a browser will take you to a web site.
FTP://….. – In a browser should open a file view to a FTP source.

 
And in our case we want;
 

RDP://….. – In a browser will ask you to launch a RDP client installed locally to the browser.
SSH://….. – Similarly, if you use this prefix, it should launch Terminal or whatever SSH client is associated to the scheme SSH://.

 
Therefore this capability is available CLIENT SIDE. It is advised that you test with your browser first a simple connection such as;
 
ssh://
 
This should prompt you to launch an external program to the browser, and you should get a terminal opening with a login prompt to the server. If this works correctly, we can configure CloudForms to do the same.
 
Configuring CloudForms
Creating the Button
We will create two buttons in a button group.
First we need a button group.
 

 
I called my button group “VM Ops”, we will add two buttons to this group after we have created them, the graphic shows these buttons present in my VM Ops group.

Create a Button for RDP
 

 
Set the Request to “launch_url_rdp”, and select the “Open URL” check box.

Create a button for SSH
 

 
Again set the request to “launch_url_ssh”, similarly check the “Open URL” check box.
Recap
We have two buttons in a button group, both of which launch a request called “launch_url_”, type being SSH or RDP.

Automate Methods
The buttons call into Automate to an instance named “launch_url_”. We need to create instances and methods for the buttons to follow.

Copy Request Class
First copy the ManageIQ/System/Request Class to an enabled domain of your choice.
If you already have domain with the request class present you can use this class and bypass this step. Continue with Creating Instances.
 

 
Here is my example copied to a domain called Sample. Yours won’t have any instances or methods yet.

Create Instance for RDP
Create a new instance as follows
 

 
Set the first “meth1” connection to “launch_url_rdp”

Create Instance for SSH
Create another new instance in the same Request Class in your domain as follows;
 

 
Set the first “meth1” connection to “launch_url_ssh”

Create Methods
The instances are now created and configured to methods that do not exist, so let’s create those.

Create Method for RDP
Create a new method and enter the code shown.
 

 
The ruby method code is very simple,

Line 1 – First we load the current VM in view as an object called “VM”.
Line 2 – Log to the automate log file the hostname that we are going to use.
Line 4 – Set in the VM object loaded the attribute “remote_console_url” with the value of the  VM hostname, with the scheme set to RDP.

Create Method for SSH
Create a new method and enter the code shown.
 

 
The method for “launch_url_ssh” is virtually identical to the previous one created for “launch_url_rdp” with only the name of the method and the url scheme changing.

Try it out!
Windows/RDP Test
Navigate to a Windows VM.
 

 
You can see your new “VM Ops” button group.
 

 
Select the RDP console button, after 2-5 seconds the browser should launch your local RDP client.
You maybe prompted by your browser as follows;
 

 
CoRD is the RDP client I have installed, click Open CoRD launches the application as follows;
 

 
 
Linux/SSH Test
Navigate to a Linux VM.
 

 
You can see your new “VM Ops” button group.

 
Select the SSH console button, after 2-5 seconds the browser should launch your local SSH client, usually Terminal.
You maybe prompted by your browser as follows;

 
Terminal is default installed on Mac OS X, CentOS, Red Hat Enterprise Linux but you will need to install a terminal application on Windows machines, such as PuTTY.
 

 

Summary
This concludes how to add custom buttons to CloudForms for SSH and RDP virtual machine access.
 
Further information to the actual implementation of “Open URL” in custom buttons can be found in this ManageIQ Pull Request.
 
We will improve this blog in time by showing you how you can use wildcard instances and assertions in Automate so that you have “launch_url_console”, and instances and methods automatically select the right scheme based on the operating system type. Also some more robustness around using public or private ip addresses and hostnames.
Quelle: CloudForms