Blog post WIP
This commit is contained in:
parent
a4184bb0c5
commit
67395704d1
1 changed files with 158 additions and 0 deletions
158
blogpost/ihsm-hiig-blog.txt
Normal file
158
blogpost/ihsm-hiig-blog.txt
Normal file
|
|
@ -0,0 +1,158 @@
|
|||
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.
|
||||
#
|
||||
Loading…
Add table
Add a link
Reference in a new issue