To Build a Better Bullpen, Better Know the Bull
Apollo #3 - Understanding Some Threats on the Horizon for Web3
Gitcoin’s grant round 7 is wrapping up soon. If you believe Web3 needs Web3-native security, please consider contributing - anything and everything is greatly appreciated as we continue this work and research!
Last week's KERNEL discussions began with the tale of Chesterton's Fence: An English gentleman tears down a fence he believes shouldn't be there, and as a result is mauled by the bull in the bull pen. Most of the conversations focused on the bullpen - on the barriers and structures Web3 is rebuilding or replacing. At Guer, as we're focused on encryption and security, we thought we would dedicate a little time to bull as well. After all, in order to build a better bullpen, we should know the bull!
Start with a $5 Wrench
No security discussion is complete without the $5 wrench! https://xkcd.com/538/
In online security, there's an unspoken number of attack vectors that, as designers of these systems, we should attempt to take into account. There are some approaches, such as social engineering, which may always be some sort of $5 wrench, and beyond what we can control within our systems. There are others which target vulnerabilities between layers of the tech stack, such as certain Man-In-The-Middle attacks, which may result from limited systematic perspective or technical limitations at the time of development. I bring up the wrench to keep into perspective what's within our scope and capacity, while remaining practical.
One of the last conferences we attended was the RSA Conference in SF, just weeks before shutdown. From the conversations we had there, it was clear there are two emerging attack vectors which have the security community particularly concerned: Hypervisor Attacks, and DNS Hijacking.
In many ways, moving to remote, decentralized, and networked systems helps minimize the "Wrench Risk"; there are less single points of failure that can be socially manipulated. But as more of our computing occurs on someone else's hardware, we are also introducing new risks.
The Cloud Is Just Someone Else's Computer...
After some digging, I can attribute this best-selling sticker to Chris Watterson. http://www.chriswatterston.com/blog/there-no-cloud-getting-1-sticker-mule-marketplace
This meme from the early days of cloud computing is as true as ever. That's not to say that the cloud has not evolved and grown into sophisticated, capable infrastructure over the past decade; on the contrary, it is beyond what most envisioned. Cloud Storage and Cloud Compute are now joined by secured compute, serverless, edge services. But at the end of the day, you're still running your processes on someone else's hardware. At the end of the day, you're trusting someone else's computer, or more likely, a virtual computer running simultaneously with other virtual computers in a complex deployment of hardware.
This is where the hypervisor comes in - the supervisor of supervisors. In this case, a supervisor is the kernel for an OS. As the manager of kernels, the hypervisor has control and visibility over everything within the virtual machines it manages. The vulnerabilities of a compromised hypervisor are endless. As we push more and more computing onto remote hardware, the appeal of hacking a hypervisor becomes greater, as does our need to secure it. This is doubly true when we're using remote computers for security, especially generating keys and certificates.
The Bare Metal Bullpen
If the hypervisor is an application or firmware running at most basic levels of our stack, then to protect against hypervisor attacks, we must go beyond to the hardware level. This is our bare metal bullpen! Bare metal security, in this case, focuses mostly on Trusted Execution Environments, or TEE's. This allows the CPU - independent of any other hardware - to directly execute critical functions in a secured, verifiable environment.
Bare metal security allows us to securely and remotely compute and verify*,* which is especially valuable in decentralized environments. This means we can distribute the risk of key generation and distribution across the network, with less concern for compromised local hardware or remote services. And while TEE's are far from perfect - there are concerns with Return-Oriented Programming Attacks, and attestation services are very centralized - they are a significant step towards securing against attacks on other people's hardware.
At Guer, our transport-layer security protocol combines this bare metal bullpen with the resiliency of Ethereum to generate and distribute symmetric keys. These symmetric keys are then used by two peers on a network to communicate securely, with the comfort that the handshake itself was secured from the CPU up. (Our protocol, in this sense, serves a similar purpose to TLS, and I'll elaborate in the next section why TLS is due for replacement)
In other words, publicly-available information goes into the CPU "black box", and publicly-available information comes out. The output is retrieved via the blockchain, and is only usable to by the intended recipients for that intended purpose. None of the randomness - the secret sauce - occurs outside of the trusted environment.
Sometimes, it's about the journey AND the destination
In November 2018, The Talos Group reported a substantial instance of "DNS Hijacking", or DNSpionage. Using a macro embedded in MS-word based job application, infected machines would redirect traffic to the hackers' IP address, enabling the attackers to intercept communications, and eventually behave as a DNS resolver. The attackers use both HTTP and DNS as methods of communication, and even issue their own X.509 certificates for use in TLS/SSL channels. The first report included victims such as the UAE and Lebanese governments, but subsequent discoveries revealed increased levels of sophistication and a second, highly successful operation known as "Sea Turtle", who for years redirected traffic in over 13 countries and 40 different organizations, including in the US.
For those interested, I would highly recommended the blog post on "Sea Turtle", as it most clearly illustrates the risks of centralized DNS and certificate authorities. The short version: attackers are targeting the very infrastructure of the web, from DNS Registrars, TLD administrators, Certificate Authorities, and telecom. Even government and military organizations have been compromised.
Many of these DNSpionage-style attacks are the result of depending on IP addresses for digital identity. IP addresses can be impersonated, redirected, falsely-certified, and re-assigned. The DNS resolvers and registrars exist to translate IP addresses into human-readable names. TLS, the most prolific means of securing data in transit, is vulnerable to the same IP-focused attacks.
DNS Hijacking undermines the very concept of "destination" in networked communications. The dependence on IP addresses as both destination and identity, and relying on a small, centralized network of organizations to verify, validate, and re-direct that traffic, jeopardizes everything about Web2.0.
If you can't be sure of where you're going, and you can't get there safely, would you really want to go?
The New Bullpen: Decentralized, Bare Metal Security
We believe Web3 can solve many of these issues. That's why Guer's protocol:
Focuses on Elliptic Curve Keypairs as our basis of identity, not IP addresses. We believe that, fundamentally, identity should come with cryptographic assurances. EC Keypairs, when used in conjunction with public, verifiable registries like ENS or Unstoppable Domains, provides an excellent basis for human-readable names without compromising security.
Shifts hardware risk from both local and remote machines to the network by relying on Ethereum (EVM) for identity verification and handshake facilitation, and networked TEEs to securely, verifiably generate. Key distribution is carried out on chain as well, reducing dependency on IP addresses.
We recognize that it's unlikely to ever fully move away from TCP/IP, but by reducing our dependence on IP and IP-related institutions for identity and as a basis for encryption, we assume less risk. By using bare metal security and the blockchain, we can decouple identity from devices and IP addresses, as well as shift computational requirements for smaller devices to the network.
Questions? Comments? Wanna discuss more? Get in touch!
APOLLO WEEK#3 UPDATES
Technical Updates
This past week had both its ups and downs, but overall, progress towards pushing the protocol towards production:
Turns out, modifying a Web2.0 app you didn't write for Web3.0 has it's challenges. A third candidate, Excalidraw, has taken to front and center, and is successfully connected to Web3, and loading / saving files to IPFS
As part of the process, users are able manage and share access to their drawings via our protocol on Ropsten
For week 4:
We're due for a video! Expect to see a video in next update with current progress
Integrating the symmetric encryption protocol (handshake) as our transport security, which will implement the security elements of the protocol
We're also due for a public demo. Expect that shortly after the video
Project Updates
From a project perspective, we wrapped up:
draft 1.0 of our "Quick Pitch" deck - a concise version of our full deck that hopefully still communicates what the protocol delivers and why, without requiring a 20 minute discussion
some back-of-the-napkin math on network and developer fees
Most importantly, this week we'll be finishing up the "quick pitch" in advance of next week's Expo Day.
If through your APOLLO experiences, you've found yourself in need of access management or security, please reach out to us on the slack. Even if there isn't a good fit, we'd love to know what, as developers, your experience is. Ultimately the protocol needs to be useful, and feedback is key!