Security Design of corosync

The corosync project intends to mitigate the following threats:

1. forged group messaging messages which are intended to fault the corosync
   executive
2. forged group messaging messages which are intended to fault applications
   using corosync apis
3. monitoring of network data to capture sensitive information

The corosync project does not intend to mitigate the following threats:

1. physical access to the hardware which could expose the private key
2. privledged access to the operating system which could expose the private key
   or be used to inject errors into the corosync executive.
3. library user creates requests which are intended to fault the corosync
   executive

The corosync project mitigates the threats using two mechanisms:

1. Authentication
2. Secrecy

Library Interface
-----------------
The corosync executive authenticates every library user.  The library is only
allowed to access services if it's GID is corosync or 0.  Unauthorized library
users are rejected.

The corosync group is a trusted group.  If the administrator doesn't trust the
application, it should not be added to the group!  Any member of the corosync group
could potentially send a malformed request to the executive and cause it to
fault.

Group Messaging Interface
-------------------------
Group messaging uses UDP/IP to communicate with other corosync executives using
messages.  It is possible without authentication of every packet that an
attacker could forge messages.  These forged messages could fault the corosync
executive distributed state machines.  It would also be possible to corrupt
end applications by forging changes.

Since messages are sent using UDP/IP it would be possible to snoop those
messages and rebuild sensitive data.

To solve these problems, the group messaging interface uses two new interfaces
interal to it's implementation:
1. encrypt_and_sign - encrypts and signs a message securely
2. authenticate_and_decrypt - authenticates and decrypts a message securely

When the executive wants to send a message over the network, it uses
encrypt_and_sign to prepare the message to be sent.  When the executive
wants to receive a message from the network, it uses
authenticate_and_decrypt to verify the message is valid and decrypt it.

Corosync uses AES256/SHA-1 which from the Mozilla Network Security
Services (libnss) library.

The internal functions utilize the following algorithms:
sha1 - hash algorithm secure for using with hmac
hmac - produces a 16 byte digest from any length input

Every message starts with a
struct security {
	unsigned char digest[20]; A one way hash digest
	unsigned char salt[16]; A securely generated random number
}

USING LIBNSS
------------
When corosync is started up libnss is initialised,
the private key is read into memory and stored for later use by the code.

When a message is sent (encrypt_and_sign):
------------------------------------------
- The message is encrypted using AES.
- A digest of that message is then created using SHA256 and based on the
  private key.
- the message is then transmitted.

When a message is received (decrypt_and_authenticate):
- A Digest of the encrypted message is created using the private key
- That digest is compared to the one in the message security_header
- If they do not match the packet is rejected
- If they do match then the message is decrypted using the private key.
- The message is processed.

Comments welcome mailto:discuss@corosync.org