Skip to main content
Cryptography

Return to Question

Notice removed Draw attention by joshperry
Bounty Ended with cpast's answer chosen by joshperry
edited title
Source Link
joshperry
joshperry
  • 13
  • 6

Symmetric mutual authentication with only one party knowingclient using a derived secret

I'm attempting to find a client/server authentication protocol that allows the client and server to authenticate each other when the client doesn't know the server secret but does have a sensitive key derived from the secret.

I would like to just use PKIasymmetric certs, but the server in this case is extremely limited in CPU and memory resources, on the order of 16MHz and 32K Ram; but it does have hardware AES support. Speed of the process is critical to the user-experience, but security is paramount.

I was thinking through it and I'd like something like this (The most secure form of each function is implicit):

ClientID (CID): Unique client identifier that ties the token to the client.

Client Token (CT): HMAC(Secret, CID)

Secret (S): A secret that the server knows. The server (or a third party that also knows the key) creates tokens through an offline commissioning process.

Client -> Server
CID, CNonce

Server -> Client (Server derives expected CT with secret and CID)
SNonce, HMAC(CT, CNonce)

Client -> Server
HMAC(CT, SNonce)

This seems to give me a few properties that I need:

  • The client can verify that the server knows the secret because it is able to HMAC CNonce with a derived CT.
  • The server can verify that the client has the token because it can HMAC the SNonce with the CT.
  • Replay attacks are mitigated by the nonces.
  • MITM attacks mitigated because the token is never transmitted.

Symmetric mutual authentication with only one party knowing a secret

I'm attempting to find a client/server authentication protocol that allows the client and server to authenticate each other when the client doesn't know the server secret but does have a sensitive key derived from the secret.

I would like to just use PKI, but the server in this case is extremely limited in CPU and memory resources, on the order of 16MHz and 32K Ram; but it does have hardware AES support. Speed of the process is critical to the user-experience, but security is paramount.

I was thinking through it and I'd like something like this (The most secure form of each function is implicit):

ClientID (CID): Unique client identifier that ties the token to the client.

Client Token (CT): HMAC(Secret, CID)

Secret (S): A secret that the server knows. The server (or a third party that also knows the key) creates tokens through an offline commissioning process.

Client -> Server
CID, CNonce

Server -> Client (Server derives expected CT with secret and CID)
SNonce, HMAC(CT, CNonce)

Client -> Server
HMAC(CT, SNonce)

This seems to give me a few properties that I need:

  • The client can verify that the server knows the secret because it is able to HMAC CNonce with a derived CT.
  • The server can verify that the client has the token because it can HMAC the SNonce with the CT.
  • Replay attacks are mitigated by the nonces.
  • MITM attacks mitigated because the token is never transmitted.

Symmetric mutual authentication with client using a derived secret

I'm attempting to find a client/server authentication protocol that allows the client and server to authenticate each other when the client doesn't know the server secret but does have a sensitive key derived from the secret.

I would like to use asymmetric certs, but the server in this case is extremely limited in CPU and memory resources, on the order of 16MHz and 32K Ram; but it does have hardware AES support. Speed of the process is critical to the user-experience, but security is paramount.

I was thinking through it and I'd like something like this (The most secure form of each function is implicit):

ClientID (CID): Unique client identifier that ties the token to the client.

Client Token (CT): HMAC(Secret, CID)

Secret (S): A secret that the server knows. The server (or a third party that also knows the key) creates tokens through an offline commissioning process.

Client -> Server
CID, CNonce

Server -> Client (Server derives expected CT with secret and CID)
SNonce, HMAC(CT, CNonce)

Client -> Server
HMAC(CT, SNonce)

This seems to give me a few properties that I need:

  • The client can verify that the server knows the secret because it is able to HMAC CNonce with a derived CT.
  • The server can verify that the client has the token because it can HMAC the SNonce with the CT.
  • Replay attacks are mitigated by the nonces.
  • MITM attacks mitigated because the token is never transmitted.
use HMAC instead of AES encryption
Source Link
joshperry
joshperry
  • 13
  • 6

I'm attempting to find a client/server authentication protocol that allows the client and server to authenticate each other when the client doesn't know the server secret but does have a sensitive key derived from the secret.

I would like to just use PKI, but the server in this case is extremely limited in CPU and memory resources, on the order of 16MHz and 32K Ram; but it does have hardware AES support. Speed of the process is critical to the user-experience, but security is paramount.

I was thinking through it and I'd like something like this (The most secure form of each function is implicit):

ClientID (CID): Unique client identifier that ties the token to the client.

Client Token (CT): SHAHMAC(CID+SecretSecret, CID)

Secret (S): A secret that the server knows. The server (or a third party that also knows the key) creates tokens through an offline commissioning process.

Client -> Server
CID, CNonce

Server -> Client (Server derives expected CT with secret and CID)
SNonce, AESHMAC(IV=CNonce, K=CTCT, PT=SNonceCNonce)

Client -> Server
AESHMAC(IV=SNonce, K=CTCT, PT=CNonceSNonce)

This seems to give me a few properties that I need:

  • The client can verify that the server knows the secret because it is able to encrypt SNonceHMAC CNonce with thea derived tokenCT.
  • The server can verify that the client has the token because it can successfully encryptHMAC the CNonceSNonce with the CT.
  • Replay attacks are mitigated by the nonces.
  • MITM attacks mitigated because the token is never transmitted.

I'm attempting to find a client/server authentication protocol that allows the client and server to authenticate each other when the client doesn't know the server secret but does have a sensitive key derived from the secret.

I would like to just use PKI, but the server in this case is extremely limited in CPU and memory resources, on the order of 16MHz and 32K Ram; but it does have hardware AES support. Speed of the process is critical to the user-experience, but security is paramount.

I was thinking through it and I'd like something like this (The most secure form of each function is implicit):

ClientID (CID): Unique client identifier that ties the token to the client.

Client Token (CT): SHA(CID+Secret)

Secret (S): A secret that the server knows. The server (or a third party that also knows the key) creates tokens through an offline commissioning process.

Client -> Server
CID, CNonce

Server -> Client (Server derives expected CT with secret and CID)
SNonce, AES(IV=CNonce, K=CT, PT=SNonce)

Client -> Server
AES(IV=SNonce, K=CT, PT=CNonce)

This seems to give me a few properties that I need:

  • The client can verify that the server knows the secret because it is able to encrypt SNonce with the derived token.
  • The server can verify that the client has the token because it can successfully encrypt the CNonce.
  • Replay attacks are mitigated by the nonces.
  • MITM attacks mitigated because the token is never transmitted.

I'm attempting to find a client/server authentication protocol that allows the client and server to authenticate each other when the client doesn't know the server secret but does have a sensitive key derived from the secret.

I would like to just use PKI, but the server in this case is extremely limited in CPU and memory resources, on the order of 16MHz and 32K Ram; but it does have hardware AES support. Speed of the process is critical to the user-experience, but security is paramount.

I was thinking through it and I'd like something like this (The most secure form of each function is implicit):

ClientID (CID): Unique client identifier that ties the token to the client.

Client Token (CT): HMAC(Secret, CID)

Secret (S): A secret that the server knows. The server (or a third party that also knows the key) creates tokens through an offline commissioning process.

Client -> Server
CID, CNonce

Server -> Client (Server derives expected CT with secret and CID)
SNonce, HMAC(CT, CNonce)

Client -> Server
HMAC(CT, SNonce)

This seems to give me a few properties that I need:

  • The client can verify that the server knows the secret because it is able to HMAC CNonce with a derived CT.
  • The server can verify that the client has the token because it can HMAC the SNonce with the CT.
  • Replay attacks are mitigated by the nonces.
  • MITM attacks mitigated because the token is never transmitted.
added 64 characters in body
Source Link
joshperry
joshperry
  • 13
  • 6

I'm attempting to find a client/server authentication protocol that allows the client and server to authenticate each other when the client doesn't know the server secret but does have a sensitive key derived from the secret.

I would like to just use PKI, but the server in this case is extremely limited in CPU and memory resources, on the order of 16MHz and 32K Ram; but it does have hardware AES support. Speed of the process is critical to the user-experience, but security is paramount.

I was thinking through it and I'd like something like this (The most secure form of each function is implicit):

ClientID (CID): Unique client identifier that ties the token to the client.

Client Token (CT): SHA(CID+Secret)

Secret (S): A secret that the server knows. The server (or a third party that also knows the key) creates tokens through an offline commissioning process.

Client -> Server
CID, CNonce

Server -> Client (Server createsderives expected CT with secret and CID)
SNonce, AES(IV=CNonce, K=CT, PT=SNonce)

Client -> Server
AES(IV=SNonce, K=CT, PT=CNonce)

This seems to give me a few properties that I need:

  • The client can verify that the server knows the secret because it is able to encrypt SNonce with the derived token.
  • The server can verify that the client has the token because it can successfully encrypt the CNonce.
  • Replay attacks are mitigated by the nonces.
  • MITM attacks mitigated because the token is never transmitted.

I'm attempting to find a client/server authentication protocol that allows the client and server to authenticate each other when the client doesn't know a secret.

I would like to just use PKI, but the server in this case is extremely limited in CPU and memory resources, on the order of 16MHz and 32K Ram; but it does have hardware AES support. Speed of the process is critical to the user-experience, but security is paramount.

I was thinking through it and I'd like something like this (The most secure form of each function is implicit):

ClientID (CID): Unique client identifier that ties the token to the client.

Client Token (CT): SHA(CID+Secret)

Secret (S): A secret that the server knows. The server (or a third party that also knows the key) creates tokens through an offline commissioning process.

Client -> Server
CID, CNonce

Server -> Client (Server creates CT with secret and CID)
SNonce, AES(IV=CNonce, K=CT, PT=SNonce)

Client -> Server
AES(IV=SNonce, K=CT, PT=CNonce)

This seems to give me a few properties that I need:

  • The client can verify that the server knows the secret because it is able to encrypt SNonce with the derived token.
  • The server can verify that the client has the token because it can successfully encrypt the CNonce.
  • Replay attacks are mitigated by the nonces.
  • MITM attacks mitigated because the token is never transmitted.

I'm attempting to find a client/server authentication protocol that allows the client and server to authenticate each other when the client doesn't know the server secret but does have a sensitive key derived from the secret.

I would like to just use PKI, but the server in this case is extremely limited in CPU and memory resources, on the order of 16MHz and 32K Ram; but it does have hardware AES support. Speed of the process is critical to the user-experience, but security is paramount.

I was thinking through it and I'd like something like this (The most secure form of each function is implicit):

ClientID (CID): Unique client identifier that ties the token to the client.

Client Token (CT): SHA(CID+Secret)

Secret (S): A secret that the server knows. The server (or a third party that also knows the key) creates tokens through an offline commissioning process.

Client -> Server
CID, CNonce

Server -> Client (Server derives expected CT with secret and CID)
SNonce, AES(IV=CNonce, K=CT, PT=SNonce)

Client -> Server
AES(IV=SNonce, K=CT, PT=CNonce)

This seems to give me a few properties that I need:

  • The client can verify that the server knows the secret because it is able to encrypt SNonce with the derived token.
  • The server can verify that the client has the token because it can successfully encrypt the CNonce.
  • Replay attacks are mitigated by the nonces.
  • MITM attacks mitigated because the token is never transmitted.
Notice added Draw attention by joshperry
Bounty Started worth 100 reputation by joshperry
edited title
Link
Maarten Bodewes ♦
Maarten Bodewes ♦
  • 94.5k
  • 13
  • 165
  • 319
added 52 characters in body
Source Link
joshperry
joshperry
  • 13
  • 6
added 4 characters in body
Source Link
joshperry
joshperry
  • 13
  • 6
Source Link
joshperry
joshperry
  • 13
  • 6