Ryan Cooke In this post, we will describe encryption as a data security measure, and examine the use of “server-side encryption” (SSE) in Infrastructure-as-a-Service providers such as Amazon Web Services. The purpose is to highlight the compromises of relying on SSE for practical data security, and how it fails to add the safeguards that have been fundamental to the use of encryption.
An extraordinarily brief history of encryption
en·cryp·tion noun /inˈkripSH(ə)n, enˈkripSH(ə)n/
the process of converting information or data into a code, especially to prevent unauthorized access.
Far from a modern invention, the use of cryptography dates back to the earliest instances of written language. Ancient Egyptian nobles wrote unusual hieroglyphs to obscure text from the uneducated; Spartan military used the “scytale” to send secret messages on parchment, essentially a ribbon wrapped around a stick; and Roman legions employed substitution ciphers to avoid captured messengers from revealing plans with great success - they weren’t “decrypted” for hundreds of years.
For most of history, encryption was a tool of governments during war, and became especially prominent during WW2 with an Allied effort to crack the German Enigma machine playing a key role in the global conflict. You’re probably familiar with Alan Turing and his exploits in codebreaking, and it’s fascinating to consider that encryption and the invention of modern digital computers are inextricably linked.
As digital communication became more mainstream through the birth of the Internet, encryption has moved from the domain of government research and militaries into a cornerstone of everyday life. The words you are reading have been encrypted in transit before displaying on your screen.
Let’s encrypt! But why?
The purpose of encryption, from its first use thousands of years ago until today, is to protect information from unintended audiences. This is critical when the medium of communication cannot guarantee that only the intended recipient is able to read the information. The key mechanism at play with encryption is to separate those who can read the information from those who can comprehend the meaning of the information.
Computer networks and radio signals (such as cellular or wifi) alone can’t offer a guarantee on who can intercept the information - any participant (a computer or antenna) in these systems can read everything being transmitted through them. Network traffic sent to a specific IP address doesn’t travel down a single wire to a computer, all traffic is merely being filtered by each computer to only their assigned address.
It became a popular hobby to snoop on strangers’ Facebook profiles while on coffee shops’ free wifi, before HTTPS was broadly enforced in 2012. [1]
For digital storage such as hard drives, physical access to the medium poses risk, and can be a factor of how many people are allowed to traffic through workplaces or data centers.
As a result, the expression “encrypted in transit (network) and at rest (disk)” is accepted as a best practice for data security, due to the fact that it’s otherwise impossible to guarantee that data isn’t being exposed to unintended parties. By encrypting the information, only parties with the ability to decrypt the information can comprehend it. This provides a second layer of protection, and encryption keys or pre-shared secrets can be exchanged once, while the information flows continuously, making encryption quite practical.
Encryption in the sky
When building software applications that run on cloud infrastructure, such as AWS, the network and storage devices powering the application are provided through virtual interfaces. This is a core benefit of using the cloud - there isn’t a need to maintain hardware, and a virtual interface will be consistent even if the underlying hardware is not. However it’s not possible to configure the network and storage devices directly, to ensure encryption is being used.
Fortunately, AWS provides configuration options to enable “server-side encryption” (SSE) when creating a new resource! Problem solved, right?
Not exactly.
The default setting for SSE is a mode of operation where Amazon manages the keys and the encryption/decryption of data on your behalf. The problem with this approach is that it invalidates the core tenet of security provided by encryption - if a party has the ability to read the data from the AWS service, they are implicitly able to decrypt the data as well. This is because Amazon will decrypt the data for all reads, and doesn’t require the reader to provide a special key or secret (Amazon is managing the keys). While access to AWS services is not as promiscuous as, say, a wifi network, it eliminates the second layer of protection that encryption is intended to provide.
Here’s an example using the aws cli. We are getting an object record.json from an S3 bucket jw-sse-test-bucket and saving it locally to read-record.json. The metadata returned in the response indicates this object is encrypted (highlighted), but the file can be read in it’s raw form without further decryption necessary.
Due to the complexity of IAM permissions in AWS, it’s extremely difficult to determine which parties have read access to which resources. Common configurations will grant broad read permissions to data stored in services like S3, and this can result in massive data leaks. The Capital One breach in 2019 is a great example - even though data was stored in a secured S3 bucket, through a series of other servers and IAM roles, nearly 100 million PII records were accessed over the course of a few hours.
A few provisos
It goes too far to say that SSE is all bad, there are disks and networks within AWS data centers that need to be secured against unauthorized access. But compared to traditional IT networks with wifi and server closets, these risks are profoundly minimized. Virtual servers on virtual networks do not see all network traffic flowing across their interfaces, and virtual storage is striped and replicated across many physical disks.
Amazon’s physical security is also world-class, with extremely prejudiced physical access. The precise location of the data centers is made public. Physical hardware that cannot be securely decommissioned from these datacenters is actually shredded to remove any lingering data.
The biggest benefit, and one not to be diminished, is that most auditors of information security programs today accept SSE as an acceptable control for implementing encryption in “transit and at rest”. Showing an auditor that SSE configuration is enabled for the AWS resources you are using is often sufficient to satisfy requests for evidence on data handling practices. And maintaining an audited security program has a net positive contribution to overall security postures.
Idle hands are playthings
However these benefits are far outweighed by risks. In my view the biggest downside is that developers are lulled into complacency, believing they are getting “extra security” by enabling SSE. It’s hard to fault them for this, as encryption in other contexts is synonymous with data security. But relying on measures that don’t actually provide protection can leave data more vulnerable due to oversight or over confidence.
Another risk is that “encryption at rest” is technically being violated, due to the fact that encrypted virtual volumes are decrypted when mounted, or in use. While most auditors don’t understand this distinction, there are vendor security teams that are starting to recognize this weakness.
By far, the biggest risk is with confusing and interconnected cloud resource permissions, which obscure the ability to easily restrict (or even be aware of) which parties can read data across cloud services. This leads to attack vectors for malicious access that are not obvious to technical teams, but have become all too common among data breaches today. Cloud services are intrinsically accessible from the wider Internet, exponentially augmenting the impact of a mistake. SSE is not the cause of this risk, but encryption was literally invented to mitigate it.
Footnotes
[1] https://techcrunch.com/2012/11/18/facebook-https/
Happy coding adventures! - The JumpWire team
