158 lines
13 KiB
Text
158 lines
13 KiB
Text
IHSMs for Grassroots Digital Autonomy
|
||
=====================================
|
||
|
||
In today's digital age, all of us depend on a number of large companies to mean well with us. To guard our data, or at
|
||
least not to abuse it too much without asking. Even if we wanted, we cannot take things into our own hands and reclaim
|
||
our digital autonomy because too much depends on too many system operators. To help small-time users and sysadmins to
|
||
fight this dependence, Jan Götte and Björn Scheuermann from HIIG have developed Inertial Hardware Security Modules, or
|
||
IHSMs. IHSMs enable low-budget servers to provide high security anywhere, even outside of well-protected datacenters.
|
||
|
||
|
||
Digital Dependencies
|
||
--------------------
|
||
|
||
The rise of networked computers has revolutionized many aspects of our modern lives. However, in lock-step with all the
|
||
quality of life improvements that the internet brought us, today we can observe a worrying trend of increasing digital
|
||
dependency. *Opting out* of the digital life on social media or e-commerce platforms becomes increasingly difficult to
|
||
sustain all the while the power of these platforms over their users is steadily increasing. Anyone who has ever had
|
||
their Twitter or Facebook account suspended for an alleged Terms of Service violation or who has been locked out of
|
||
their Google or Amaazon account pending some complicated and frustrating “account verification” process for unnamed
|
||
“security reasons” will know how acute this dependency is. What the platform decides is law. There is no way for us as
|
||
users to meaningfully challenge its decisions because we are the platform's product, not its customers.
|
||
|
||
Don't it Yourself
|
||
-----------------
|
||
|
||
The obvious solution to this state of digital dependency is for us to take things into our own hands. On this premise,
|
||
open-source projects such as Nextcloud <https://nextcloud.com/> and Mastodon <https://joinmastodon.org/> have created
|
||
de-centralized alternatives to some of the big platforms. But DIY'ing has a drawback beyond the time spent on installing
|
||
and maintaining these solutions. While open-source software has made great strides over the last decades and offers
|
||
viable alternatives to many proprietary, centralized platforms today, this software has to run on someone's computer.
|
||
This underlying physical infrastructure is where things get complicated. Today, the only real option to run one's own
|
||
digital infrastructure is to rent a server (or part of one) from one of a number of large cloud providers. And in this
|
||
case, whoever runs the data center ultimately controls access to the data stored within.
|
||
|
||
At first, this fact of life might not seem concerning. After all, a data center operator would risk a lot if it
|
||
compromised its customers' security. However, in the past we have seen several physical attacks targeting high-value
|
||
data <https://archive.md/QpvHA> <https://en.wikipedia.org/wiki/NSA_ANT_catalog>. Large companies can mitigate such
|
||
attacks by tightly controlling their entire infrastructure, from the application software down to the data center's
|
||
access control systems. For smaller organizations and private individuals, this option does not exist.
|
||
|
||
Inertial Hardware Security Modules
|
||
----------------------------------
|
||
|
||
# Gaining back control over our digital lives is a monumental task. In software, through an ecosystem of open source
|
||
# projects, we have seen steady progress throughout the last decades. But all of that open source software needs to run
|
||
# somewhere, and today that usually means renting processing time at one of the large cloud providers. Avoiding them means
|
||
# buying your own hardware, and even then, that hardware needs to be put somewhere in a data center operated by yet
|
||
# another large company. Security-wise, this is not great since whoever runs the cloud or the datacenter can technically
|
||
# access everything running inside it. In the end it comes down to physical access: Even passwords or strong encryption
|
||
# cannot (yet) prevent someone with physical access to a machine from learning everything about its contents.
|
||
|
||
At HIIG, Björn and I have asked ourselves if there might be ways to claw back control over our hardware. If we can find
|
||
a way for someone someone much smaller than an Amazon or Google to build a special physically secure server that is
|
||
invulnerable to physical attaks, this server can be put into any commercial data center while completely decoupling the
|
||
security of the data stored in it from the operator of the data center around it.
|
||
|
||
With Inertial Hardware Security Modules (short, IHSMs) we believe we have developed a strong approach towards a solution
|
||
to this problem. You can read the full paper here <https://tches.iacr.org/index.php/TCHES/article/view/9290>. The gist
|
||
of our solution is that we are able to build an enclosure that physically protects a server from any attempt at
|
||
siphoning off its secrets, no matter who tries to attack it. IHSMs are similar to a type of device used in payment
|
||
processing applications called Hardware Security Modules. Both provide a similar level of security. The main difference
|
||
is that IHSMs allow much larger systems to be protected and bump both size and computing power from that of a smartphone
|
||
to that of a server, a difference of about 100 × in space, processing power and cooling capacity. IHSMs are simple to
|
||
construct and can be built with basic tools that can be found in most electronic labs. We envision a world where small
|
||
organizations can build their own secure servers that even a hostile secret service will not be able to compromise
|
||
physically.
|
||
|
||
IHSMs work by putting the server's mainboard, CPU, and memory inside of a tamper detection “mesh.” This mesh is a very
|
||
delicate component that will sense when someone tries to cut, drill or poke through it. When tampering is detected, an
|
||
alarm is activated and all sensitive data inside the server is deleted. To make the tamper detection mesh itself hard to
|
||
tamper with, this mesh is spinning at around the speed of a washing machine during its spin cycle.
|
||
|
||
Trusting and Un-trusting
|
||
------------------------
|
||
|
||
In computer security terms, what we are doing with IHSMs is that we are “untrusting” the server's physical environment.
|
||
Computer security has a funny definition of trust that is pretty much the opposite of everyone else. In computer
|
||
security, trust is a de-facto property of something that we de-facto rely on being good. In computer security, something
|
||
trusted should be trustworthy (but does not have to be). Contrast that to the common-sense meaning, where something
|
||
trustworthy should be trusted (but does not have to be).
|
||
|
||
Untrusting the data center gives us the chance to decouple software security from physical security. Using an IHSM, a
|
||
small organization such as the HIIG, the Chaos Computer Club, or a small company can operate software on a physical
|
||
foundation that is as secure as that of the large cloud companies, but with no one but themselves holding the keys to
|
||
the data.
|
||
|
||
Examples for applications where this increased security matters are group chat, cloud photo storage, and calendar and
|
||
contact synchronization systems. All of these already encrypt the network connection between their users phone or laptop
|
||
and the server, but only rarely encrypt the actual data stored on these servers.
|
||
|
||
# In terms of computer security, these platform behemoths are trusted parts of our lives. Not trusted as in
|
||
# “Google/Facebook/Amazon is a trustworthy company”, but trusted in the computer security sense of the world: they are
|
||
# de-facto trusted. We act as if we trust them, without actually considering whether they really are worth our trust. We
|
||
# need them, and we depend on them not acting against our interests. But if they abuse our trust, there is nothing we can
|
||
# do about it if we even notice.
|
||
#
|
||
# Confusingly, this computer security meaning of trustedness is the exact opposite of our common-sense understanding of
|
||
# trust. In a common-sense world, a trustworthy thing should be trusted (but does not have to be). In the computer
|
||
# security world, a trusted thing should be trustworthy (but does not have to be). While the two seem close at first,
|
||
# there is a large difference in meaning. Understanding this difference is necessary to understand the things computer
|
||
# security people say.
|
||
#
|
||
# The computer security concept of de-facto trust is counter-intuitve. However, its complement, which has no common-sense
|
||
# counterpart, is very useful. In computer security, the opposite of a trusted component is an untrusted component.
|
||
# Untrusted does not mean untrustworthy. An untrusted part is simply one that does not *need to be* trusted for things to
|
||
# work. An example for an untrusted part is a coffeeshop wifi network. While we need it to get online, we do not have to
|
||
# trust it to guard our data in any way since all our connections are authenticated and encrypted anyway using the TLS
|
||
# protocol that underlies HTTPS. In this case, by basing everything on an authenticated and encrypted network protocol, we
|
||
# remove trust from the coffeeshop wifi. We still need the wifi, but because our connections on top of it are encrypted
|
||
# separately, we do not have to care anymore whether someone is snooping on it or not.
|
||
#
|
||
# From a computer security point of view, untrusting as many parts of a system as possible is highly desirable. The fewer
|
||
# parts you trust, the fewer you can concentrate your security engineering efforts on. Not only does this save time and
|
||
# money, the overall system will actually become more secure by doing this as more time is spent on less parts, leading to
|
||
# better-quality results.
|
||
|
||
# opposite of what everybody else calls trust. Take the sentence “Riley trusts Alex to take care of his cat.” In an
|
||
# everyday, common-sense way this sentence parses quite easily. Apparently Riley is out of town for a vacation or
|
||
# work-related trip and needs someone to feed their cat. Among Riley's friends, Riley asked Alex because they are
|
||
# reliable. The key concept here is that this sentence implies that *because Alex is trustworthy*, Riley asked them to
|
||
# take care of their cat.
|
||
#
|
||
# In computer-land, trust means something very different. While in the common-sense interpretation trusting something
|
||
# implies that that thing is “trustworthy”, in computer security things are exactly backwards. In computer security, a
|
||
# trusted part of a system is one that has to be trusted because without it the system doesn't work. The distinction here
|
||
# is that this part *should* better be “trustworthy”, but that is not a given.
|
||
#
|
||
# Now, why should we care about this rather pedantic distinction? That is because we have to keep in mind this linguistic
|
||
# quirk to correctly understand what security people mean when they are talking about computers. If we interpret things a
|
||
# computer security person says in a common-sense way, they might seem to make sense at first, but this important detail
|
||
# can get lost in translation.
|
||
#
|
||
# There is a useful concept in computer security called “untrustedness”. In computer security, a thing is untrusted when
|
||
# we do not rely on it being trustworthy.
|
||
|
||
|
||
#The concept of a trusted thing as “something that must be trustworthy” is useful in computer security, but its
|
||
#complement is even more interesting. If there
|
||
|
||
|
||
# The rise of networked computers has revolutionized many aspects of our modern lives. For most of us, the internet has
|
||
# made everyday things more convenient and improved our overall quality of life. Large platform companies can serve
|
||
# millions or even billions of users with only a few hundred people in design and development. However, these same
|
||
# economies of scale that have brought us incredibly polished software products that improve our lives in many ways, also
|
||
# have a dark side.
|
||
#
|
||
# Through the last few decades, we can observe a shift in how we use computers in our lives. The computer systems we use
|
||
# have become increasingly complex and have proliferated throughout all aspects of our modern lives. At the same time, the
|
||
# internet's economies of scale have led to the operators of these systems consolidating. For instance, while in the 2000s
|
||
# an online business would have had to operate its own physical servers in a datacenter somewhere, today the entire
|
||
# internet rests on a small number of cloud computing providers.
|
||
#
|
||
# On one axis, there is the shift towards increasing integration of digital systems into our lives. On the other axis
|
||
# there is the shift towards large centralized operators providing the infrastructure for most of these systems. These two
|
||
# effects compound each other to produce a steeply rising dependence towards system operators. On a national level, this
|
||
# is seen as a threat of an emerging concept dubbed “digital sovereignty”, and is perceived to be an acute issue. However,
|
||
# on an individual level, things are not better in any meaningful way--they are just talked about less.
|
||
#
|