Commit ac44311e7fb9afaa854b436c02d85da7e47008e6
Created desirable properties for a secure channel (markdown)
Dominic Tarr committed on 5/7/2015, 6:06:26 PMParent: 224f833309480f08256d66cd41428e63172a1682
Files changed
| desirable-properties-for-a-secure-channel.md | added |
| desirable-properties-for-a-secure-channel.md | ||
|---|---|---|
| @@ -1,0 +1,73 @@ | ||
| 1 | +here is a list of properties that I think are desirable in a p2p secure channel. It is assumed that peers already know the pubkeys of a server. It may not be possible to support _all_ of these properties in one protocol. | |
| 2 | + | |
| 3 | +1. content is forward secure | |
| 4 | +2. server verifies client identity | |
| 5 | +3. client verifies server identity | |
| 6 | +4. server knows client has verified | |
| 7 | +5. client knows server has verified | |
| 8 | +6. resists replay attack | |
| 9 | +7. resists man-in-the-middle attack | |
| 10 | +8. prevents cold calling/war-dialing (only accept calls from clients that know who server is) | |
| 11 | +9. eavesdropper cannot learn client key | |
| 12 | +10. eavesdropper cannot learn server key | |
| 13 | +11. eavesdropper cannot confirm client key | |
| 14 | +12. eavesdropper cannot confirm server key | |
| 15 | +13. replay attack cannot learn who is authorized | |
| 16 | +14. unauthorized client cannot learn identity of server. | |
| 17 | + | |
| 18 | +## requirements | |
| 19 | + | |
| 20 | +how to achieve the above properties | |
| 21 | + | |
| 22 | +## 1. forward secure content | |
| 23 | + | |
| 24 | +Use diffie-helman style key exchange, an ensure a different key is used every connection. | |
| 25 | + | |
| 26 | +## 2,3. verify identities | |
| 27 | + | |
| 28 | +challenge the remote peer to provide a signature of a nonce. | |
| 29 | + | |
| 30 | +## 4,5. know the remote has verified you | |
| 31 | + | |
| 32 | +acknowledge their signed challenge by signing it. | |
| 33 | + | |
| 34 | +## 6. resist replay attack | |
| 35 | + | |
| 36 | +force peer to respond (sign) something you know is unique (nonce) (see 2,3) | |
| 37 | + | |
| 38 | +# 7. resist man in the middle attack | |
| 39 | + | |
| 40 | +verify identities & client must abort connection if response was from unexpected server. | |
| 41 | +Use diffie-helman to exchange keys (or box every message) | |
| 42 | + | |
| 43 | +# 8. prevent cold-calling/war-dialing | |
| 44 | + | |
| 45 | +client must prove it knows the server's pubkey. | |
| 46 | +This treats the pubkey as a write capability. | |
| 47 | + | |
| 48 | +one method would be to box the hello to the server's pubkey. | |
| 49 | +Another option, would be to hmac with the server's pubkey. | |
| 50 | + | |
| 51 | +# 9, 10. protect client/server keys from eavesdropper | |
| 52 | + | |
| 53 | +do not send long term keys as plaintext. | |
| 54 | +It shouldn't be necessary to send the server key at all, given that the client has know business connecting to a server they don't know (see 8, prevent war dialing) | |
| 55 | + | |
| 56 | +# 11, 12. eavesdropper cannot confirm client/server | |
| 57 | + | |
| 58 | +If an eavesdropper happens to know the client or server's key, are they able to know it is those peers talking? This property protects the client's privacy in particular. The server is likely to be a staticly addressed server, so their key is likely to eventually become public knowledge. Although, in a p2p protocol it's likely that the server may also move. | |
| 59 | + | |
| 60 | +The client on the other hand, is likely to be a mobile device that changes ip addresses. Being able to identify / observe their key would allow you to know track their location. | |
| 61 | + | |
| 62 | +This property is stronger than 9,10 even if the eavesdropper knows the keys, they are unable to confirm the identity of the peer. | |
| 63 | + | |
| 64 | +# 13. a replay attack cannot learn whether a given client is authorized on this server. | |
| 65 | + | |
| 66 | +It would be easy for a eavesdropper to record client hellos, and then send them to random servers to see whether that client is authorized on that server. If the server rejects that connection before the client has proven their identity then this leaks information from the server's access list. The server should wait until the client has proved their identity before rejecting a connection. | |
| 67 | + | |
| 68 | +# 14. unauthorized client cannot learn identity of server. | |
| 69 | + | |
| 70 | +To realize this property it would be necessary for the client to auth to the server first. | |
| 71 | +This property seems reasonable - "hi this is Alice, is Bob there?" if Bob isn't talking to Alice, or if it's a wrong number the server responds "sorry wrong number" and hangs up. This will require an extra round trip, because a challenge must be issued to the client. | |
| 72 | + | |
| 73 | +This property would prevent an active attacker from verifying who a given server is. | |
Built with git-ssb-web