Security the Google Way

The latest RISC-V workshop was held at Google. In the middle of the day, there was an interesting presentation by Eric Grosse. He used to be VP of security at Google but he has recently returned to more hands-on engineering work. His talk was titled Trust, Transparency, and Simplicity.

Eric got an awakening in December 2009 when it became clear that Google had been hacked by the Chinese military. This became known as Operation Aurora (Google was not the only company targeted, others like Juniper Networks and Morgan Stanley were, too). Eric's first tenet is that you need to know your adversary. Some nation states are extremely competent, he said, but even the less competent can still cause trouble. His list was China, Russia, the "5 Eyes"—Australia, Canada, New Zealand, the United Kingdom, and the United States—and the "friendly" states like Korea and France. Even Syrian rebels, who are not that good but "good enough."

Security is a multi-layered effort. The most fundamental is secure communications. HTTPS use has continued to grow, especially in the last year. The graph below shows the percentage of secure connections used by Google's Chrome browser, by operating system. Google has also put a lot of less visible effort into encryption of internal links.

Eric says that authentication is currently broken. Lost credentials, such as passwords, are the #1 way that users lose their data. Passwords are simply too hard to use safely. One big step is to make sure that you use two-factor verification, either with a physical security key or a text message sent to your phone. As Eric puts it, "You should already be using this technology."

The third step is to make sure that patches are applied. One big vulnerability is not new stuff but stuff that has been known about for years.

In the fall of 2014, Eric got his next awakening when the rowhammer vulnerability was discovered. One thing that he discovered is that rowhammer had been known for two years previously without the security community being notified. Google has a 90-day policy when they find a vulnerability: 90 days to work out what to do or say until it is made public. This works a lot better than the old policy where Google would notify the vendor and maybe years later the vendor would update it. If they see an adversary exploiting a vulnerability, they have a seven-day rule. Hardware is different, of course, in that you can't just swap out all the machines to defend against rowhammer or similar issues.

Eric intriguingly talked about the great BIOS lockdown of 2011. In the Q&A, someone asked if there is any information publicly available about this since it doesn't seem to be on the net. "Maybe not," Eric said. What happened was that there was a credible concern that by accident something might cause “lots of machines”, aka most PCs, to get their BIOS zeroed out and the machines bricked until you could replace the flash part. Too few parts, too few burners, too few people. So quietly the industry came up with ways to better lock down the BIOS and avert catastrophe.

One maxim is that complexity is the enemy of security. Today's systems are way too complicated and undocumented. The best approach is open source software (and hardware) and ruthless pruning. But there are mysterious binaries in firmware that users don't have any visibility into. Luckily, firmware is too hard for most adversaries and they stick to easier stuff.

A paranoid's choice of CPU should be RISC-V. It has the critical advantage of openness. But there needs to be an active effort to stop adding more and more features over time. Plus extra features need to be removed to compensate, to keep things simple. Eric recommended looking at the CHERI security extension.

You can watch a video of Eric's presentation (35 minutes):

Previous: RISCy Business: Next Hogan Evening at ESD Alliance Is RISC-V