proxmox-mirrors/mirror_corosync
1
0
Fork 0
mirror of https://git.proxmox.com/git/mirror_corosync synced 2025-08-05 20:38:04 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Describe latest security system using SOBER, SHA1, and HMAC.

Browse Source 
(Logical change 1.52)


git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@159 fd59a12c-fef9-0310-b244-a6a79926bd2f
This commit is contained in:
Steven Dake 2004-08-09 21:32:37 +00:00
parent b70fdf8555
commit 6089c11fb7
1 changed files with 51 additions and 66 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

117
SECURITY
View File

@ -1,10 +1,12 @@
----------------------------
Security Design of openais
----------------------------
The openais project uses code from the libtomcrypt package (www.libtomcrypt.org)
for most of the algorithms described in this document. The libtomcrypt code has
a public domain license.
***
All cryptographic software in this package is subject to the following legal
notice:
This package includes publicly available encryption source code which,
together with object code resulting from the compiling of publicly
available source code, may be exported from the United States under License
Exception TSU prsuant to 15 C.F.R Section 740.13(e).
***
Security Design of openais
The openais project intends to mitigate the following threats:
@ -44,98 +46,81 @@ Group messaging uses UDP/IP to communicate with other openais executives using
messages. It is possible without authentication of every packet that an
attacker could forge messages. These forged messages could fault the openais
executive distributed state machines. It would also be possible to corrupt
end applications by forging updates
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. ctr_encrypt_and_sign - encrypts and signs a message securely
2. ctr_authenticate_and_decrypt - authenticates and decrypts a message securely
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
ctr_encrypt_and_sign to prepare the message to be sent. When the executive
encrypt_and_sign to prepare the message to be sent. When the executive
wants to receive a message from the network, it uses
ctr_authenticate_and_decrypt to verify the message is valid and decrypt it.
authenticate_and_decrypt to verify the message is valid and decrypt it.
These two functions utilize the following algorithms:
yarrow - secure pseudo random number generator
pkcs #5 alg #2 - Converts a random and secret key into a larger key
md4 - hash algorithm secure for using with yarrow and pkcs
sha1 - hash algorithm secure for using with hmac
hmac - produces a 20 byte sha1 digest from any length input and a 16 byte key
blowfish - cipher algorithm - encrypts one block of data
ctr - Counter mode of ciphering - encrypts variable length data blocks
hmac - produces a 16 byte digest from any length input
sober - pseudo random number generator and stream cipher
The hmac algorithm requires a 16 byte key.
The blowfish algorithm requires a 16 byte key.
The ctr algorithm requires a 16 byte nonce.
The sober algorithm requires a 16 byte private key.
The sober algorithm requires a 16 byte public initial vector.
The private key is read from disk and stored in memory for use with the
pkcs #5 alg #2 operation.
sober algorithm to generate the three required keys.
Every message starts with a
struct digest {
struct security {
unsigned char digest[20]; A one way hash digest
};
struct salt {
unsigned char salt[16]; A securely generated random number
};
struct sec_hdr {
struct digest;
struct salt;
}
The sec_hdr.digest is never hashed or encrypted by the algorithms described.
The sec_hdr.salt is never encrypted, but is hashed by the algoriths described.
When a message is sent (ctr_encrypt_and_sign):
----------------------------------------------
1. yarrow is used to create a 16 byte random number (salt) using the md4
When a message is sent (encrypt_and_sign):
------------------------------------------
1. sober is used to create a 16 byte random number (salt) using the md4
algorithm
2. pkcs #5 alg #2 is used with the salt and private key to create a 48 byte
key. This 48 byte key is split into 3 16 byte keys. The keys are the
hmac key, the blowfish key, and the ctr nonce key. pkcs uses the md4
algorithm.
3. The ctr nonce and blowfish key from step #2 are used to setup the ctr cipher
for use with blowfish.
4. The data of the packet, except for the sec_hdr, is encrypted using
the ctr cipher that was initialized in step #3.
5. The salt is stored in the sec_hdr header of the outgoing message.
2. sober is keyed with the private key and the initial vector is set to the
salt. Then a 48 byte key is read from the sober algorithm. This 48 byte
key is split into 3 16 byte keys. The keys are the hmac key, the sober key
and the sober initial vector.
3. A sober instance is keyed with the sober key and sober initial vector
from step #2.
4. The data of the packet, except for the security header, is encrypted using
the sober cipher that was initialized in step #3.
5. The salt is stored in the security header of the outgoing message.
6. The hmac is initialized with the hmac key generated in step #2.
7. The message, except for the sec_hdr.digest, is hmaced to produce a digest
7. The message, except for the security header, is hmaced to produce a digest
using the sha1 algorithm.
8. The digest is stored in the outgoing message.
9. The message is transmitted.
When a message is received (ctr_decrypt_and_authenticate):
---------------------------------------------------------
1. yarrow is used to create a 16 byte random number (salt) using the md4
algorithm
2. pkcs #5 alg #2 is used with the salt and private key to create a 48 byte
key. This 48 byte key is split into 3 16 byte keys. The keys are the
hmac key, the blowfish key, and the ctr nonce key. pkcs uses the md4
algorithm.
3. The ctr nonce and blowfish key from step #2 are used to setup the ctr cipher
for use with blowfish.
4. The hmac is setup using the hmac key generated in step #2 using sha1.
5. The message is authenticated, except for the sec_hdr.digest.
When a message is received (decrypt_and_authenticate):
------------------------------------------------------
1. sober is keyed with the private key and the initial vector is set to the
salt in the received message. Then a 48 byte key is read from the sober
algorithm. This 48 byte key is split into 3 16 byte keys. The keys are the
hmac key, the sober key and the sober initial vector.
2. The sober key and sober initial vector from step #1 are used to key a
new sober instance.
3. The hmac is setup using the hmac key generated in step #1 using sha1.
5. The message is authenticated, except for the security header.
6. If the message was not authenticated, the caller is told of the result.
The caller ignores the message.
7. The message is decrypted, except for the sec_hdr, using the ctr
initialized in step #3.
7. The message is decrypted, except for the security header, using the sober
algorithm in step #2.
8. The message is processed.
This does consume some resources. It ensures the private key is never shared
openly. All messages are authenticated and encrypted. An exposure of
one of the nonce key, blowfish key, or hmac key can only be used to
attack the key relating to the algorithm. Finally every key used is
randomly unique (within the 2^128 search space of the input to pkcs) to ensure
that keys are never reused, nonce's are never reused, and hmac's are never
reused in combination with each other.
openly, that messages are authenticated, that messages are encrypted, and that
any key exposure of the sober encryption key, sober initial vector, or hmac
key can only be used to attack one of the algorithms. Finally every key used
is randomly unique (within the 2^128 search space of the input to sober) to
ensure that keys are never reused, nonce's are never reused, and hmac's are
never reused.
Comments welcome mailto:openais@lists.osdl.org