SECURITY

   1 Security Design of corosync
   2
   3 The corosync project intends to mitigate the following threats:
   4
   5 1. forged group messaging messages which are intended to fault the corosync
   6    executive
   7 2. forged group messaging messages which are intended to fault applications
   8    using corosync apis
   9 3. monitoring of network data to capture sensitive information
  10
  11 The corosync project does not intend to mitigate the following threats:
  12
  13 1. physical access to the hardware which could expose the private key
  14 2. privledged access to the operating system which could expose the private key
  15    or be used to inject errors into the corosync executive.
  16 3. library user creates requests which are intended to fault the corosync
  17    executive
  18
  19 The corosync project mitigates the threats using two mechanisms:
  20
  21 1. Authentication
  22 2. Secrecy
  23
  24 Library Interface
  25 -----------------
  26 The corosync executive authenticates every library user.  The library is only
  27 allowed to access services if it's GID is corosync or 0.  Unauthorized library
  28 users are rejected.
  29
  30 The corosync group is a trusted group.  If the administrator doesn't trust the
  31 application, it should not be added to the group!  Any member of the corosync group
  32 could potentially send a malformed request to the executive and cause it to
  33 fault.
  34
  35 Group Messaging Interface
  36 -------------------------
  37 Group messaging uses UDP/IP to communicate with other corosync executives using
  38 messages.  It is possible without authentication of every packet that an
  39 attacker could forge messages.  These forged messages could fault the corosync
  40 executive distributed state machines.  It would also be possible to corrupt
  41 end applications by forging changes.
  42
  43 Since messages are sent using UDP/IP it would be possible to snoop those
  44 messages and rebuild sensitive data.
  45
  46 To solve these problems, the group messaging interface uses two new interfaces
  47 interal to it's implementation:
  48 1. encrypt_and_sign - encrypts and signs a message securely
  49 2. authenticate_and_decrypt - authenticates and decrypts a message securely
  50
  51 When the executive wants to send a message over the network, it uses
  52 encrypt_and_sign to prepare the message to be sent.  When the executive
  53 wants to receive a message from the network, it uses
  54 authenticate_and_decrypt to verify the message is valid and decrypt it.
  55
  56 Corosync uses AES256/SHA-1 which from the Mozilla Network Security
  57 Services (libnss) library.
  58
  59 The internal functions utilize the following algorithms:
  60 sha1 - hash algorithm secure for using with hmac
  61 hmac - produces a 16 byte digest from any length input
  62
  63 Every message starts with a
  64 struct security {
  65         unsigned char digest[20]; A one way hash digest
  66         unsigned char salt[16]; A securely generated random number
  67 }
  68
  69 USING LIBNSS
  70 ------------
  71 When corosync is started up libnss is initialised,
  72 the private key is read into memory and stored for later use by the code.
  73
  74 When a message is sent (encrypt_and_sign):
  75 ------------------------------------------
  76 - The message is encrypted using AES.
  77 - A digest of that message is then created using SHA256 and based on the
  78   private key.
  79 - the message is then transmitted.
  80
  81 When a message is received (decrypt_and_authenticate):
  82 - A Digest of the encrypted message is created using the private key
  83 - That digest is compared to the one in the message security_header
  84 - If they do not match the packet is rejected
  85 - If they do match then the message is decrypted using the private key.
  86 - The message is processed.
  87
  88 Comments welcome mailto:discuss@corosync.org