Symmetric key as proof of ownership of a session?

Question

I have a question, or rather multiple questions that all relate to the same topic.

I am building an application with both a frontend (FE) and a backend (BE). All communication between FE and BE is protected with TLS. The BE contains an endpoint on which the frontend can register a new session. When setting up such a new session, a few things happen:

1. FE sends a request (TLS protected) to BE, sharing a Curve25519 public key from a freshly generated Curve25519 keypair.
2. BE receives this request. Creates a new Curve25519 keypair, uses HKDF to calculate a shared secret (using as input FE public key, BE private key and a salt) and ultimately create a new symmetric session key (ChaCha20-Poly1305)
3. BE creates a new 32-byte (256-bit) session ID and keeps it in memory together with the session key.
4. BE sends back the session ID + salt + public key from freshly generated Curve25519 keypair.
5. FE uses BE public key + salt + FE private key to calculate same secret and create the session key.

Again I want to emphasise all of the above communication (so the request + response) happens over TLS. For all future communication, FE will encrypt all requests using the session key. The encrypted request is encoded to base64, and put in a JSON request body together with the unencrypted sessionID:

{
    "sessionID": "SomeString",
    "encryptedRequest: "base64 encrypted request"
}

These requests are then send (along with the unencrypted session ID) over a TLS connection, resulting in double encryption. When BE receives these requests, it will lookup the required session key by using the provided session ID. Then, it will decrypt the encryptedRequest field and forward it to the appropriate endpoint.

Some questions I have with this setup are:

1. Because all requests are encrypted with the session key, can that act as a form of proof that the client is the real owner of the session ID? e.g. If the session ID somehow is stolen, it can still not be used to communicate to the backend as you still would need to have ownership over the shared secret.
2. How much added security does this setup give if for some reason the TLS connection is broken into? (e.g. due to MITM, or because the TLS-level encryption is broken)
3. Does this setup aid in API obfuscation? E.g. client-side you can install software that - prior to TLS encryption occurring - can inspect all incoming and outgoing traffic. For my application, they would only see requests that are already encrypted. Is it easy to work around this?

I'm curious about what you guys think. I've been experimenting a bit with these topics (i'm by no means a cryptography expert) and I would love to learn more.

Answer 1

1. Because all requests are encrypted with the session key, can that act as a form of proof that the client is the real owner of the session ID? e.g. If the session ID somehow is stolen, it can still not be used to communicate to the backend as you still would need to have ownership over the shared secret.

That depends. I don't see any explicit check for this defined. I also don't see any specific mention of defusing replay attacks (in both ways, as there is only one encryption key, it seems). Also, 32 bit isn't much to avoid either integer overruns or collisions, so an attacker with another valid TLS key may retry until such an ID is created.

2. How much added security does this setup give if for some reason the TLS connection is broken into? (e.g. due to MITM, or because the TLS-level encryption is broken)

None, as you don't perform any authentication of or after the key exchange.

3. Does this setup aid in API obfuscation? E.g. client-side you can install software that - prior to TLS encryption occurring - can inspect all incoming and outgoing traffic. For my application, they would only see requests that are already encrypted. Is it easy to work around this?

No, it won't aid in API obfuscation, and yes, it is easy to work around this because of 2. And if you have an unencrypted part then an attacker can do an MITM there.

Better to just rely on TLS.