As part of evaluating potential technologies to use for Paeony I need a list of threats I can evaluate those technologies against. This document tries to capture the most basic possible scenario (two users sending messages to each other) and the attendant threats. I can then use this list in creating threat models for potential technologies to determine which are the best to choose.
1 The Players
Without loss of generality we can talk about exactly three users.
Alice This is the owner of the device (or devices) we are trying to protect. We will often call the device ’Alice’ but we mean ’the device Alice owns and is using’. For our threat modeling purposes we assume Alice has complete control over her device. The attacks where this isn’t true are device security issues that are out of scope for this article.
Frieda This is the owner of the device that Alice wishes to communicate with. I intentionally haven’t used the more traditional ’Bob’ because as we will see below we can’t be sure if Frieda is a friend or attacker. In fact, Frieda might be an attacker and not even know it. Unlike Alice, we do explicitly concern ourselves with attacks made possible if Frieda’s device’s security is compromised.
Eve This is an attacker who wants to compromise (in a variety of ways outlined below) the communication between Alice and Frieda.
2 STRIDE Attack Model
Microsoft has published its STRIDE attack model. See here for the details. I find this a generally useful model so I’ll use it here.
3 The four canonical scenarios
Connecting Alice 1 and 2 Alice owns two devices, called Alice 1 & Alice 2, she wishes to ’join’ them so they can securely recognize each other.
Sending messages between Alice 1 and 2 Having been introduced Alice wants messages to be transmitted between Alice 1 & Alice 2
Connecting Alice and Frieda Alice wishes to communicate with Frieda which means she needs some way of obtaining an authenticator for her and vice versa
Sending messages between Alice and Frieda Having obtained authenticators, Alice and Frieda wish to communicate
These four scenarios are the ’meat and potatoes’ of Paeony. In fact there are many more scenarios to consider but let’s start at the beginning.
The first and third scenarios, about connecting, are extremely difficult to really explore without more details of how they intend to work, the very thing we are here to evaluate! And scenario 2 & 4 are very similar. So to make the whole thing less annoying I’m going to explore a combination of scenarios 3 & 4 and argue that the same patterns apply to 1 & 2.
4 Connecting Alice & Frieda/Sending Messages between Alice & Frieda
4.1 Spoofing
In this attack Eve wants to convince Alice that she is Frieda. This attack can occur at several different points in the identity life cycle.
Introduction Attack Somehow Alice and Frieda agreed on some sort of authentication scheme to identify themselves to each other. This could be symmetric keys (using some variant of Needham-Schroeder to generate session keys) or asymmetric keys. But somehow these identification materials were exchanged. Did they come from some kind of public directory? Did they come via an insecure mechanism like email? Did they come from some kind of web of trust? Did they come from some kind of physical device exchange (e.g. NFC, BlueTooth, a picture of something like a barcode, a cable, infrared, etc.)? Whatever the mechanism that was used to exchange identifiers its subject to attacks where Eve could substitute her authenticator for Frieda’s.
Brute Force Attack Alice and Frieda, at run time, need to authenticate themselves to each other based on the previously exchanged proofs. In theory Eve could try to break the algorithmic security of the authentication mechanism.
Device Attack With all the zero days and other device attack vectors around it’s quite possible that Frieda’s device was compromised and along with it her identity proof. There are some hardware based protections against this but fundamentally the system has to accept that device compromises will happen (not can, but will) and have a plan for dealing with it. Yes, we are now talking about mitigation, not prevention, but we can’t stick our heads in the sand and pretend that device compromises won’t happen. How does the system handle device compromises where a user’s authenticators are compromised?
Update Attack All proof materials generally need to be updated at some point. I am explicitly not addressing the previously described device attack but more normal key roll over. The system has to have a mechanism to enable such roll overs and that mechanism is also a point of attack.
4.2 Tampering
In a tampering attack Eve alters the content of the messages being sent between Alice and Frieda in a manner that neither can detect. Note, again, that if Frieda’s device has been compromised by Eve then tampering becomes easier but we’ll worry about that sort of attack one layer up in the context of specific Peony applications.
4.3 Repudiation
A normal repudiation attack is where someone is able to send a message and then deny they ever sent the message. But I’m going to expand repudiation to also include attacks where a user can’t repudiate what they sent. Who the heck wants a system where every act you take is recorded and attested to forever? Can you imagine if every conversation you ever have had would be recorded and then verified as essentially a kind of mini contract that can follow you around until the end of your days? Ick. So we need to tighten up our definition of repudiation attacks into two forms.
Internal Repudiation In this attack the system behaves in such a way that Alice cannot be sure who sent her a message at the time she receives the message.
External Repudiation We consider it a flaw in the system if Frieda can prove (in the geek sense, not the legal sense) to Eve that Alice sent a particular message.
4.4 Information Disclosure
Traffic Analysis with Eve against Alice Eve should not be be able to tell where Alice is or if she knows where Alice is, who Alice is communicating with.
Traffic Analysis with Eve against Frieda and Alice Even if Eve knows where both Alice and Frieda are and is able to see both of their messages it should not be easily possible for Eve to determine that Frieda and Alice are communicating.
Traffic Analysis with Frieda Frieda should not be able to tell where Alice is.
Header exposure to Eve Eve should not be able to see any of the routing or other message wrapper data in the messages sent by Alice.
Message content exposure to Eve Eve should not be able to see any of the content of the messages sent by Alice.
4.5 Denial of service
There are always simple brute force denials of service. If Eve can determine where Alice or Frida are then she can just open the fire hose on them. But depending on how the communication infrastructure works there might be other ways to shut down or at least hinder communication between Alice and Frida that doesn’t require knowing either of their locations.
4.6 Elevation of privilege
Short of very specific holes in the technology being used this is usually just a variant of spoofing.