Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Cloud Security //

Google

8/25/2017
04:33 PM
Simon Marshall
Simon Marshall
Simon Marshall
50%
50%

Google: Big Cloud, Tiny Titan Chip

Google develops a tiny chip to close a big security hole before it opens. Is there a tiny Titan in your future, too?

If you take a slice through Google's Cloud Platform, you'll see Google-designed components everywhere. Google hardware, Google-controlled firmware stack, Google-curated OS images, a Google-hardened hypervisor, coupled with an intimidating physical presence at its data centers. Google is so concerned about security that it likes to build its own kit.

This self-sufficiency ethos was reinforced as it unveiled the technical detail behind its new Titan security chip. Google is talking about this now, even though the chip was launched earlier this year, because the chip has spent some time in the wild in Google data centers and the results are promising.

Google is aiming big with its tiny chip; it's designed to close hardware security back doors before they're even opened. If the chip finds something anomalous, it won't even let the hardware boot. That approach seems like a sledgehammer, but it's designed to defeat strong, evolving exploits from nation states.

"That level of adversaries certainly have an incentive to hack or to have influence over the security of hardware," said Dan Cornell, principal at Denim Group, a firm that builds secure systems for technology companies. According to Cornell, the chip-led approach is timely as nation states gear up for cyberwar.

Titan is a secure, low-power microcontroller created to ensure that systems always boot from the last known good state. Using verifiable code, Titan establishes the hardware root of trust for cryptographic operations in Google's data centers by verifying the firmware/software stack before booting -- allowing or disallowing access to network resources based on the result. If there's been a hardware/firmware tamper, the system just isn't allowed to wake up.

This is particularly effective in countering a new crop of firmware attacks, which, for example, target rewritable firmware chips such as a BIOS chip or hard drive controller. While BIOS manufacturers are addressing this problem, Google has gone a step further and designed an approach that pulls the power plug before anything even comes on line. Titan boots its own firmware first, and only then allows the host firmware to boot.

The chip is another building block in Google's attempt to punch-up its security creadentials and try to narrow the gap with leaders AWS and Microsoft Azure. However, Google was quick to stress that the chip is only one component of its all-round security in the cloud. Certainly, Google does not expect the chip to be the main money-spinner.

"We're not pinning our hopes on this as (a separate) investment. The most important thing to note is that Titan is one piece of the puzzle, and Google Cloud delivers end-to-end security," said a Google spokesperson.


You're invited to attend Light Reading's 11th annual Future of Cable Business Services event. Join us in New York on November 30 for the premier independent conference focusing on the cable industry's continuing efforts in the commercial services market -- all cable operators and other communications service providers get in free.

Google declined to respond to questions related to the total cost to develop Titan, or whether it would consider licensing or selling the technology to other companies.

Simon Marshall has worked within and around the telecom and IT industries for 21 years. Simon cut his teeth as editor-at-large at totaltelecom.com in the late Nineties, drove strategic communication and product marketing plans for Qualcomm, Neustar and Redknee during the Noughties, and lives today as a technical consultant, active tech news junky and content underwriter at Security Now.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Manchester United Suffers Cyberattack
Dark Reading Staff 11/23/2020
As 'Anywhere Work' Evolves, Security Will Be Key Challenge
Robert Lemos, Contributing Writer,  11/23/2020
Cloud Security Startup Lightspin Emerges From Stealth
Kelly Sheridan, Staff Editor, Dark Reading,  11/24/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-20934
PUBLISHED: 2020-11-28
An issue was discovered in the Linux kernel before 5.2.6. On NUMA systems, the Linux fair scheduler has a use-after-free in show_numa_stats() because NUMA fault statistics are inappropriately freed, aka CID-16d51a590a8c.
CVE-2020-29368
PUBLISHED: 2020-11-28
An issue was discovered in __split_huge_pmd in mm/huge_memory.c in the Linux kernel before 5.7.5. The copy-on-write implementation can grant unintended write access because of a race condition in a THP mapcount check, aka CID-c444eb564fb1.
CVE-2020-29369
PUBLISHED: 2020-11-28
An issue was discovered in mm/mmap.c in the Linux kernel before 5.7.11. There is a race condition between certain expand functions (expand_downwards and expand_upwards) and page-table free operations from an munmap call, aka CID-246c320a8cfe.
CVE-2020-29370
PUBLISHED: 2020-11-28
An issue was discovered in kmem_cache_alloc_bulk in mm/slub.c in the Linux kernel before 5.5.11. The slowpath lacks the required TID increment, aka CID-fd4d9c7d0c71.
CVE-2020-29371
PUBLISHED: 2020-11-28
An issue was discovered in romfs_dev_read in fs/romfs/storage.c in the Linux kernel before 5.8.4. Uninitialized memory leaks to userspace, aka CID-bcf85fcedfdd.