Publish-Subscribe Authentication and Encryption (PSAE)

This draft proposal is based on the Salt design for secure pub-sub.

Scope

Authentication and encryption of distributed 0MQ publish-subscribe systems in which subscribers and publishers are known to each other in advance.

Components of the System

  • Master: responsible for authentication, master key distribution, and publishing encrypted application data.
  • Minion: responsible for receiving encrypted application data.

Overall Operation

  • PSAE uses public/private asymmetric encryption (e.g. RSA) for authentication and master key exchange. Each PSAE peer has a public key-private key pair. Public and private keys are static.
  • PSAE uses a static master key for symmetric data encryption (using e.g. AES). The master will regenerate its master keys (one per domain) arbitrarily.
  • Each PSAE message consists of a clear header specifying the encryption mechanism, and an encrypted body.
  • The master is pre-configured with the public keys of all the minions it will work with.
  • Each minion is pre-configured with the public key of the master(s) it will work with.
  • PSAE assumes that public keys are exchanged in advance by some unspecified secure mechanism.

Minion Authentication

Authentication is by domain, which is an application-level access container. Minions are identified by name, and verified by their public keys.

A minion authenticates as follows:

  • It opens a REQ socket and connects to the master, which has bound a ROUTER socket.
  • It sends an AUTHENTICATE command to the master. The body consists of the desired domain, minion name, and minion signature. The minion signature consists of the six letters "MINION", encrypted using the minion's private key. The body is encrypted using the master's public key.
  • The master decrypts the AUTHENTICATE body using its private key, and verifies the domain and minion name. It then decrypts the signature using the minion's public key, and verifies it. If this succeeds, the master replies with AUTHENTICATE-OK to the minion.
  • The body of AUTHENTICATE-OK consists of the current master key, master signature, and port number for the specified domain. The master signature consists of the six letters "MASTER", encrypted using the master's private key. The body is encrypted with the minion's public key.
  • The minion decrypts the AUTHENTICATE-OK body using its private key, then decrypts the master signature using the master's public key, and verifies that the result is equal to the master's public key. If this succeeds, the minion will use the decrypted master key to decrypt data published by the master.

The format of the AUTHENTICATE command is:

  • Frame 0: "AUTHENTICATE" (0MQ string)
  • Frame 1: security mechanism (0MQ string, e.g. "RSA")
  • Frame 2: encrypted body (length-specified blob)

Where the encrypted body is formatted as follows:

[size][domain]                  as one byte followed by 0MQ string
[size][minion name]             as one byte followed by 0MQ string
[size][signature]               as one byte followed by blob

The format of the AUTHENTICATE-OK command is:

  • Frame 0: "AUTHENTICATE-OK" (0MQ string)
  • Frame 1: security mechanism (0MQ string, e.g. "RSA")
  • Frame 2: encrypted body (length-specified blob)

Where the encrypted body is formatted as follows:

[size][domain]                  as one byte followed by 0MQ string
[port]                          as two-byte integer, in network order
[size][signature]               as one byte followed by blob

Data Distribution

  • The minion connects a SUB socket to the specified port on the master host, which is bound to a PUB socket.
  • The master encrypts and sends data using the master key.
  • The minion decrypts data using the master key.
  • If the master regenerates its master data key, the minion will be unable to decrypt traffic, and will re-authenticate to get the new data key before continuing.

The format of publish-subscribe data is:

  • Frame 0: filter (0MQ string, unencrypted)
  • Frame 1: security mechanism (0MQ string, e.g. "AES")
  • Frame 2: encrypted body (length-specified blob)

The filter may be left empty.

Encryption Mechanisms

  • "RSA" - the body is encrypted using the RSA public key of the intended recipient.
  • "AES" - the body is encrypted using the AES master key.
  • "CLEAR" - the body is not encrypted in any way.

Man in the Middle Attacks

A MIM attacker cannot create fraudulent AUTHENTICATE or AUTHENTICATE-OK commands because it cannot create valid signatures, not knowing the private keys.

A MIM attacker can create fraudulent data messages and can modify the filter.