How does SMB authentication work?

Question

When I learned about the inner workings of the TLS protocol and what exactly it protects a connection against, I was surprised to learn that even asymmetric encryption can be defeated by a MITM attack - as all the attacker has to do is replace the certificate with their own. This is why CAs exist, as a form of authentication to make sure the certificate holder is who they claim to be.

Last time I used samba was a good while ago and people generally strongly advised against using it over the internet, seen at it had no encryption features. I'm now taking another stab at it, and quickly found things have changed. According to Samba SMB Encryption - How safe is it?, azure services apparently make use of it over the internet.

So, when requiring SMB encryption, how is it ensured that I'm actually talking to the server, and not just sending my data and credentials to a MITM who has just switched out the 'certificate' mid-flight?

---

I suspect the answer may be something to do with hashing the credentials and using it as some sort of symmetric key (it's known by both sides already, but unknown to the attacker) like in Password-authenticated key agreement, but I'm mostly only being able to find jumbled up information from multiple SMB versions that I can't make heads or tails of. Some articles I read even seemed like they were straight off of chatgpt - long but with little coherence and the same information repeated 2 or 3 times throughout.
I thought about whether to post this on the SuperUser SE but this seems like much more of a cryptography question than actually asking how to use a specific piece of software.

Answer 1

Well the answer was in the linked post Samba SMB Encryption - How safe is it?. More concretely, the microsoft article linked within: Encryption in SMB 3.0: A protocol perspective.

I couldn't really read it before as I was quite out of context. Only after finding out about the existence of password-based cryptography (which lead to password-authenticated key agreement) from tags suggestions in my initial question did it start to make sense.

Quote:

Cryptographic keys

Ko = SMB3KDF (Ki, Label, Context)

SMB3KDF() is defined as the KDF algorithm in Counter Mode, as specified in [SP800-108] section 5.1, with 'r' value of 32 and 'L' value of 128, and HMAC-SHA256 as the PRF.

• Ki – Key derivation key, used as an input to the KDF. For SMB 3.0, Ki is the SessionKey.
• Label – the purpose of this derived key, encoded as string and length for SMB 3.0.
• Context – the context information of this derived key, encoded as string and length for SMB 3.0.
• L – An integer that specifies the length of the derived keying material Ko, L is 128 bits for SMB 3.0 cryptographic keys. Note that L is a constant since all SMB 3.0 keys are 16 bytes in length (SigningKey, EncryptionKey, DecryptionKey, and ApplicationKey).
• Ko – Keying material output from the KDF, a binary string of length L, where Ko is the leftmost L bits of KDF result.

---

ServerInKey (ClientToServer) = SMB3KDF (SessionKey, "SMB2AESCCM\0", "ServerIn \0")
EncryptionKey(Client) = DecryptionKey(Server) = ServerInKey(ClientToServer)

ServerOutKey (ServerToClient) = SMB3KDF ( SessionKey, "SMB2AESCCM\0", "ServerOut\0")
EncryptionKey(Server) = DecryptionKey(Client) = ServerOutKey(ServerToClient)

---

The server and client generate the encryption keys upon session establishment of the primary channel. If the server is configured for encryption (...) the server generates the EncryptionKey and DecryptionKey (...), the client must also generate its encryption and decryption keys.

(...)

Note: These cryptographic keys are all derived from the SessionKey. As a result, SMB 3.0 signing and encryption is as secure as the session key. Not only must this key be unique and very random, but also it needs be kept secret.

There's a lot more information in the article, but the KDF algorithm part answered my question. KDF stands for Key Derivation Function. The SessionKey is used to derive it.

---

For the sake of thoroughness, there's a few places information can be found about the SessionKey, first of which is more microsoft documentation: SessionKey Generation

Virtual circuit session keys (SessionKeys) are generated on CIFS servers.

The definition for CIFS linked:

Common Internet File System (CIFS): The "NT LM 0.12" / NT LAN Manager dialect of the Server Message Block (SMB) Protocol, as implemented in Windows NT.

Alternatively, there's an encryption overview from the samba wiki which states:

The encryption key and algorithm to use for the connection is determined by one of the following methods:

• Kerberos (...)
• NTLM (NT LAN Manager) authentication. When NTLM authentication is used, the session key is derived from the shared secret, which is the user or machine account password in the database. The choice of cryptographic algorithms are essentially hardwired into the NTLM protocol, and are not really able to be configured.
• SCHANNEL (...) It uses the shared machine account password as the secret between the client and server

So the sessionkey is either derived from the credentials directly, or negotiated with the server by using communications encrypted using those credentials (hard to tell exactly without digging into the specifications).
In short, the information that is present on both the client and the server. The information the man in the middle has no knowledge of.

The samba wireshark decryption guide on the samba wiki may also be helpful, as well as How SMB signing works from the infosec SE.