[WIP] MSC2957: Cryptographically Concealed Credentials #2957
Conversation
uhoreg
changed the title
|
|
||
| ### ... | ||
|
|
||
| ## Potential issues |
There was a problem hiding this comment.
It would be similar to registration. Though of course if you're using the same password for 4S, you'd also need to re-encrypt all your 4S secrets.
There was a problem hiding this comment.
In order to be able to re-encrypt SSSS secrets you have to have them unencrypted, though. If you use "resent password" you typically don't have your password, and thus can't decrypt them. Meaning all your secret store is effectively lost.
There was a problem hiding this comment.
Right. I was thinking password changing rather than password reset. For password changing, you can re-encrypt. For password reset, you'd have to re-create the SSSS secrets, cross-signing keys, etc.
There was a problem hiding this comment.
what i was more getting at is: how do you recover your account if you forget your password? it feels like a recovery code could work - could we just give the user their private key derived from the password to store offline as a way to get back in if they forget their human password?
| tag|`\<Matrix ID>`|`A<sub>pub</sub>`|`C<sub>pub</sub>`|`S<sub>pub</sub>", 16), | ||
| and calculates HKDF(K<sub>conf</sub>, "", "`security check|`\<Matrix | ||
| ID>`|`A<sub>priv</sub>", 3), giving a number between 0 and 7. The client then | ||
| displays the emoji (or the text equivalent) from the SAS verification emoji |
There was a problem hiding this comment.
how useful really is this UX? given there's a 12.5% chance of the right emoji appearing later even if things have gone wrong, what does it buy us? am worried the additional UX complexity could confuse casual users even more than usual.
There was a problem hiding this comment.
Since that is something people would likely write on a paper, it might be a good idea to also give the option of numbers, instead of emoji. While emoji are nice for comparing in device verification, numbers are significantly easier to write down.
Also, what if you don't write down the emoji / numbers and forget them? Realistically quite a few people will do just that.
There was a problem hiding this comment.
Since that is something people would likely write on a paper, it might be a good idea to also give the option of numbers, instead of emoji. While emoji are nice for comparing in device verification, numbers are significantly easier to write down.
Possibly. Or offer both the emoji version and the text equivalent. The idea behind using emoji was that it's something that's easier for people to recognize, as opposed to trying to remember a number. But this part is very much open for discussion.
There was a problem hiding this comment.
Isn't this purpose of protecting against impersonating homeservers already served by X.509 TLS certificates, which are already verified? I am not sure a user overriding an invalid cert would care about this, either. And if so, that sounds more like something that should be addressed in UX of clients, and not on this level.
Of course there is the angle of protecting against compromised CAs/roots, which is a nice improvement - but perhaps that is better adressed in how that level of PKI is handled?
There was a problem hiding this comment.
In addition to protecting against compromised CAs/roots, or an attacker who is able to gain control of a valid cert somehow, it would also protect against attacks such as typosquatting.
|
|
||
| If a user tries to log into their account using a server that does not follow | ||
| this proposal may send the user's password to the server by trying to log in | ||
| using the current `POST /login` endpoint. This can be partially mitigated in |
There was a problem hiding this comment.
can we not have a different password for those using the legacy /login flow, separate to the 4S/3C one, much as we do today? So users on old clients (or who want to script their client without understanding this MSC ;) can just grab an AT using an insecure oldschool login - completely independently of whether the account also has 3C set up?
There was a problem hiding this comment.
The problem is that old, existing clients will just POST /login the password people enter in them. So the only way this can be securely implemented is, if we update all old clients to not do that automatically, and then wait until all stable distros have that updated etc.
| - relatively simple to implement | ||
| - the data stored on the server cannot be used (apart from attacking the | ||
| underlying cryptographic operations) to authenticate with the server | ||
| - the user can verify that the server that they are authenticating against is |
There was a problem hiding this comment.
This sounds like a step backwards of that other MSC to have decentrel identities, a that proposes to have your account exist on multiple servers.
There was a problem hiding this comment.
I don't think that this conflicts with decentralized identities. Even with decentralized identities, there is some point at which you have to tell a server that you want to use it. This would be analogous to the "registration" part, and then with subsequent logins, you can verify that you're connecting to that same server.
|
|
||
| ... | ||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
Maybe compare how this is better than just having the client hash the password w/ a salt (from the server) and sending the hash to the server, and the server treats the hash as a password and hashes the hash in its db?
There was a problem hiding this comment.
If I'm understanding what you're suggesting, I think one main difference is that it would be open to replay attacks. i.e. if someone listens in on your login attempt, they'll see your hashed password, and they can then use that to log in as you.
There was a problem hiding this comment.
Actually, if I understand your proposal, it is somewhat similar to parts of SCRAM. In SCRAM, the client does PBKDF2 followed by HMAC to generate a ClientKey. The server stores a hash of ClientKey. This part sounds like it's the same as your proposal. But to avoid replay attacks, rather than sending the ClientKey to the server, the client uses the ClientKey to generate an HMAC of some messages, which the server is able to verify. (More specifically, the client calculates the HMAC using the hashed ClientKey as the key, and then XORs it with the ClientKey and sends that to the server. The server can calculate the same HMAC, since it has the hashed ClientKey, XORs the HMAC with what it received from the client to recover the ClientKey, and then hashes the recovered ClientKey to check that it matches the stored hashed ClientKey.)
| - HKDF(K, S, I, L): HKDF-SHA-256 where K is the initial key material, S is the | ||
| salt, I is the info, and L is the number of bits to generate. | ||
|
|
||
| #### Registration |
There was a problem hiding this comment.
Could you give a less-mathematically cookbook on these (Registration & Login) flows? Like, what is the core idea that is keeping this secure?
There was a problem hiding this comment.
I can try to do so, though there isn't a single core idea that is keeping this secure, since different aspects provide different parts of the security. If you want a "main" part, it would probably be turning the password into a Curve25519 key pair (the authentication key), which allows the server to verify that you have the password without needing access to the password itself. Using a Curve25519 key also allows us to do more complicated operations (like combining the ephemeral keys), which provide other security properties.
But yes, there is certainly room for making this less "mathematically cookbook".
There was a problem hiding this comment.
I think we could easily list a couple of higher level goals that this MSC tries to solve, for example:
- Avoid sending passwords to the server
- Establish an emoji fingerprint of the server when registering which can be used to identify it when we login again.
And then perhaps how each of these goals is achieved. For example the first stages on how we avoid sending the password.
- The password is expanded into a Curve25519 keypair using PBKDF2
- The public key and the PBKDF2 parameters are transfered to the server using a shared secret that was established using ephemeral ECDH.
This could also live besides the math at the start of each such step.
There was a problem hiding this comment.
Agreed with the earlier comments here, that a more high-level explanation would help others to digest this. For example, I eventually noticed that the proposal repeatedly uses DH key exchange followed by AES encryption to construct a secure channel within the channel. Giving the reader a heads-up that this is coming (1) makes it easier to understand what's going on when they get there and (2) gives you a place to explain why it's there and what it's doing.
There was a problem hiding this comment.
I have added some words, which hopefully makes things a bit clearer.
There was a problem hiding this comment.
Here's kind of a crazy suggestion, so feel free to take it or leave it.
But, reading over the 2nd Bellovin and Merritt EKE paper Augmented Encrypted Key Exchange, there's a lot of similarity between that classic paper and the approach proposed here. On the one hand, duh, they're both trying to do the same thing. But I think it's deeper than that -- the two "feel" much more similar to each other than either one is to, say, SRP, right? (And fortunately all the EKE patents expired years ago, so I don't think you have anything to worry about there.)
Here's the crazy part: Are they actually close enough that you could structure your protocol as a fix/update/modernization for AEKE? Then you might be able to borrow a big portion of whatever security analysis has already been done for AEKE. If you could frame it as a series of deltas, and you could show that each delta makes the new protocol strictly better than the old one, then that could save a ton of work. (And remove a ton of uncertainty.)
Anyway, like I said this is kind of crazy. I'm not an expert in either protocol, so maybe I'm seeing more than is really there.
| @@ -278,6 +306,10 @@ two ways. | |||
| emoji, providing a hint to users that the client does not support this | |||
| authentication method. | |||
|
|
|||
| ## Possible future work | |||
|
|
|||
| TODO: combine 2FA? | |||
There was a problem hiding this comment.
If we have UIA on /login (#2835) (might be needed to properly implement this on protocol level anyways), and dynamic UIA (#2839) then 2FA could just be added as another UIA stage.
It feels to soru like 2FA would go beyond the scope of this MSC and would better live as its own MSC, which builds on #2835 and #2839
There was a problem hiding this comment.
Yeah. This is more ildly wondering about whether there are any security benefits from integrating 2FA, versus tacking it on as separate thing. I don't think there are any benefits, but I'm not sure enough at the moment that I want to rule it out completely. So this is mainly a note to think about it.
| `authentication key|` + MatrixID, 256), which is called the "authentication | ||
| key", and the corresponding public key A<sub>pub</sub> | ||
|
|
||
| The client sends to the server (encrypted with AES-256-CBC using the key |
There was a problem hiding this comment.
I know this is implied in DH and upon careful reading obvious, but as readers might wonder why we're going through the trouble of using HKDF when generating the IV. It's so the server can recreate all the info that is needed to decrypt Apub.
I think clarifying and listing that the server goes through the same steps of expanding the shared secret into an AES and MAC key like the client does would lower the chances of people being initially confused about what's going on. Especially since the initial two steps introduce the expectation that we're going through each step of the client and server. As it is we're left wondering if the server ever completes the DH step and gets to K1.
| - the user's desired Matrix ID | ||
| - C<sub>pub</sub> | ||
|
|
||
| The server generates its own ephemeral Curve25519 key pair |
There was a problem hiding this comment.
Are we doing something about receiving a Curve25519 key from Malory that lies at the point of infinity like we had to for SAS verification? If so could we mention that, if there's no need for it could we mention that as well?
There was a problem hiding this comment.
Yes, we're binding the generated keys to the public keys by including them in the HKDF info parameter. I guess I can throw something in the MITM section.
|
|
||
| ### Argon2 | ||
|
|
||
| Argon2 would likely be a better option than PBKDF2 for generating a key from |
There was a problem hiding this comment.
Presumably AES-GCM wasn't considered for the same reason?
There was a problem hiding this comment.
Sort of. By now, there's probably enough implementations of AES-GCM that we could use it if we wanted to. But we're using AES-CBC here for a few reasons. We're already using CBC in olm and SSSS, and we don't use GCM anywhere else (yet -- /me looks at MLS). But another reason is that we do not want the encryption of Kconf (in the server's first response in the login stage) to be authenticated, as noted in the "Offline computation" section. So that encryption cannot use GCM, and it seems kind of silly to use two different encryption modes in the same protocol unless there's a strong reason that both are needed.
| - K<sub>base</sub> = PBKDF2(Password, Salt, I, 256), where I is an iteration | ||
| count chosen by the client (K<sub>base</sub> can be used as the Secret | ||
| Storage key) | ||
| - the Curve25519 private key A<sub>priv</sub> = HKDF(K<sub>base</sub>, "", |
There was a problem hiding this comment.
Don't we need to clamp the private Curve25519 key like it's explained here under the Computing secret keys section?
There was a problem hiding this comment.
Yeah. Most implementations probably do the clamping already, but we can probably mention it for completeness.
| - A<sub>pub</sub> | ||
| - R, and I, which can be used to reconstruct the PBKDF2 parameters | ||
|
|
||
| The server stores A<sub>pub</sub>, R, and I, as well as the result of |
There was a problem hiding this comment.
Making this a list and thus putting the math on a separate line would aid in readability.
| - HKDF(K, S, I, L): HKDF-SHA-256 where K is the initial key material, S is the | ||
| salt, I is the info, and L is the number of bits to generate. | ||
|
|
||
| #### Registration |
There was a problem hiding this comment.
I think we could easily list a couple of higher level goals that this MSC tries to solve, for example:
- Avoid sending passwords to the server
- Establish an emoji fingerprint of the server when registering which can be used to identify it when we login again.
And then perhaps how each of these goals is achieved. For example the first stages on how we avoid sending the password.
- The password is expanded into a Curve25519 keypair using PBKDF2
- The public key and the PBKDF2 parameters are transfered to the server using a shared secret that was established using ephemeral ECDH.
This could also live besides the math at the start of each such step.
Co-authored-by: poljar <poljar@termina.org.uk>
| - K<sub>MAC</sub> = HKDF(K<sub>1</sub>, "", `mac key|` + MatrixID + `|` + | ||
| C<sub>pub</sub> + `|` + S<sub>pub</sub>, 256) | ||
| - Salt = HKDF(R, "", `salt|` + MatrixID), where R is a random byte string | ||
| - K<sub>base</sub> = PBKDF2(Password, Salt, I, 256), where I is an iteration |
There was a problem hiding this comment.
What about providing alternatives to get K_base than PBKDF2, e.g. using gpg somehow (think: use your yubikey as login!) Or is that more a place for future MSCs?
turt2live
added
the
needs-implementation
| 3) | ||
|
|
||
| The client displays the emoji (or text equivalent) from the SAS verification | ||
| emoji list corresponding to the number given by the last calculation, and |
There was a problem hiding this comment.
I agree with @ara4n's earlier comment on this aspect. Allowing the attacker a 1 in 8 chance of success is generally not sufficient.
Just to make sure I'm following this part correctly: The core problem here is that you need to verify the identity of the server, but you can't rely on (or don't have) the SSL/TLS layer certs, and you can't be sure that the client has anything stored locally. Like, maybe this is a new device. Right?
If so, then yeah, this is a hard problem with a well known set of unsatisfying solutions. The emoji thing is like a modern version of the ASCII art that SSH used to generate.
Some other ideas:
- Could you get back to the easier case where you do have some sort of PKI? Like, maybe you get one cert for your TLS layer (ie Cloudflare/nginx/etc) and a totally different cert for the back end of this auth protocol. Then life is much easier, as long as you can trust your cert authority. All the client has to do is verify the cert.
- What if you could have the client generate a sort of "cert" for the server at registration time? Maybe this is just a copy of the server's public key, signed or MAC'd with a key derived from the password that only the user knows.
- Then when the user goes to log in, the server provides this "cert" in the auth params.
- Before doing anything else, the client first verifies the signature or MAC, using the private/secret key derived from the password. If the verification fails, then the client terminates the connection.
- In the protocol, the client uses this verified public key for the server. If there's an MITM who doesn't have the corresponding private key, they shouldn't be able to learn any of the secrets.
There was a problem hiding this comment.
The emoji check is something that I'm not entirely committed to. It was just an interesting idea that I came up with, and wondered if it would be useful. But the emoji check does two things: 1) it gives the user a way to see if they typo'ed their password (with some reasonable-ish probability), and 2) sort-of authenticates the server. Thing 1 I would classify as nice-to-have, and thing 2 is very optional, given that the server gets fully authenticated later on.
The problem with the client-generated "cert" idea is that it allows an attacker to test different passwords to see if it is the right one by seeing which one yields a successful signature/MAC, which allows an an attacker to do a login attempt and then use the result to perform an offline attack. That's the reason why I only take 3 bits (8 emoji) is that it gives some help to the user without giving too much information to an attacker. Though that number may need to be fine tuned. Or we could just scrap it if it turns out to be a not-so-great idea.
There was a problem hiding this comment.
Ok, that makes a lot of sense. If the emoji is mostly to verify the password, then some chance of failure is fine.
The problem with the client-generated "cert" idea is that it allows an attacker to test different passwords to see if it is the right one by seeing which one yields a successful signature/MAC
Yeah, any password-derived key has to come from a good password-based KDF, like bcrypt / scrypt / argon2 with properly chosen parameters. Otherwise it's wide open to attack.
| K<sub>conf</sub> values calculated by the client and server will be different. | ||
| If the user later connects to the server without the man-in-the-middle, the | ||
| value of K<sub>conf</sub> encrypted and sent by the server will be different | ||
| from the value calculated by the client during registration, yielding a 7/8 |
There was a problem hiding this comment.
Using my crazy "cert on first use" approach above, these detection probabilities go to 8/8.
| which define a client and server role where the server does not store | ||
| password-equivalent data, are suitable for client-server authentication. | ||
|
|
||
| TODO: compare with various PAKEs (e.g. SRP, OPAQUE) |
There was a problem hiding this comment.
Yes, it would really help to see some discussion here. How is the problem here different from the problem solved by PAKEs? And why is a PAKE not sufficient here? Otherwise it's tempting to say, just grab the current best PAKE (is that OPAQUE?) and run with it.
There was a problem hiding this comment.
Basically, the tl;dr for why I'm not suggesting a PAKE is that most PAKEs are complicated to implement (is there a good OPAQUE implementation for, say, JavaScript that's readily available?) and/or tied to specific math problems that will be hard to replace if they are shown to be vulnerable. Whereas the scheme presented here uses primitives that are used elsewhere in Matrix and can be easily replaced by equivalent primitives.
There was a problem hiding this comment.
I was going to say, it's probably easier to implement whatever existing scheme than to design your own. Then I started reading OPAQUE... yikes.
SRP and SCRAM are much simpler and use primitives much closer to what you're using. They also have lots of implementations. What makes them not a good fit?
I'm not saying you can't build your own PAKE or PAKE-like thing, only that it's really hard. And if you screw up, you'll get the Telegram treatment where the "serious" infosec / crypto people decide to laugh at you instead of looking at your fixed version.
All that said, what I've seen so far looks pretty reasonable. I'll find some time later this week to do a full read-through and provide more in depth comments then.
There was a problem hiding this comment.
I think SRP still requires implementing low-level math stuff. But there's probably at least some decent implementations lying around.
SCRAM is pretty decent too, and could be used, though I'd probably want to make some tweaks to it to tighten things up a bit. The main issue with SCRAM is the one vulnerability that I have mentioned in the section where I talk about SCRAM. But aside from that, it should be usable.
I'm not saying you can't build your own PAKE or PAKE-like thing, only that it's really hard. And if you screw up, you'll get the Telegram treatment where the "serious" infosec / crypto people decide to laugh at you instead of looking at your fixed version.
Yeah, completely agreed. This is basically just an idea that I had in the middle of the night, and I believe that it's better than SCRAM, but I don't want to push this forward until it's been reviewed by other people who are knowledgeable in crypto.
| a password. However, this proposal uses PBKDF2 for compatibility with Secret | ||
| Storage, which used PBKDF2 due to the availability of implementations of both | ||
| algorithms. (For example, WebCrypto includes a PBKDF2 implementation, but not | ||
| an Argon2 implementation.) In the future, we may switch to Argon2 for both |
There was a problem hiding this comment.
FWIW there are some reports that bcrypt is stronger than Argon2 for interactive use, where the computation time is < 1000 ms. Note that this is coming from committee members of the Password Hashing Competition, who authored a competing system (Pufferfish).
https://twitter.com/TerahashCorp/status/1155129705034653698
https://www.reddit.com/r/crypto/comments/hvbgt7/alternatives_to_bcrypt/
…oc into msc-cryptographic-logins
|
Some thoughts: Mixed feelings. I am all for exploring, implementing, and enforcing stronger authorization methods than passwords. One very neat thing with this proposal is the aspects of deniability, and the UX aspects of deriving cryptographic keys from a password - it allows for adoption without user-side key management. It seems well thought-through and come from a good place. However, it still does not sit right with me and I wonder if such a detailed flow belongs in the protocol spec. Slightly related is that it's relatively complex to and password-based auth may not be the best/single way moving forward - consider DIDs, authenticating via hardware tokens, TPMs, or their cryptocurrency wallet, for example. Or maybe servers will want to provide auth via SSH keys or GPG signatures. Also the aspect of being very Matrix-specific and therefore not likely to be integrated with other IdPs or auth systems ("Just fall back to legacy passwords for that" is the obvious answer and kind of inherent but I hope you can see how this poses a barrier for both adoption and integration). As a cryptographic scheme, it is as you say fairly simple. But implementation is another thing; few non-Element clients, and barely any bridges, have implemented existing E2EE capabilities as it is. As such, imploring servers and clients to support this MSC may effectively both fragment the ecosystem and close the door to future auth mechanism with better security characteristics or different desirable tradeoffs. In particular, as DIDs become first-class citizens, things will change a lot. An MSC solving for auth involving cryptography should (or must?) be aligned with that. If Matrix had been a closed platform, most of these concerns wouldn't be that relevant. But for the long-term, there is risk with making this part of the spec at this point. And I hope I don't sound too critical and dismissing here - proficient effort with good intentions of improving user security have been put into this proposal. But at the end of the day I think as formulated it does not belong as a normative MSC. So, my question to @uhoreg and reviewers: What are your thoughts on the above? Would it be possible to facilitate both this MSC and potential future developments like the ones mentioned above in a more general but less normative flow that could capture arbitrary auth via client-side crypto? And, until then, if one would still like to push this through, it should still be possible to get most of the benefits through an IdP following this flow, if nothing else to demonstrate the UX and serve as a PoC and stepping stone. |
I wrote up some ideas along these lines in #3744 |
Rendered
discussion about this (and #3262): #secure-login:matrix.vgorcum.com