search

Cosmian / cover_crypt

Implementation of the Covercrypt attributes based encryption algorithm
Other
12 stars 1 forks source link

Possible vulnerabilities in the encryption process. #96

Open tbrezot opened 1 year ago

tbrezot commented 1 year ago

Attack on the policy

Description

The policy is not a cryptographic key, but it is a really sensitive object.

An attacker could trick a user into encrypting data for the wrong right (e.g. one the attacker is entitled to) by providing him with a modified policy.

For example, exchanging the attribute values of the Top Secret attribute with those of the Low Secret attribute would lead to actually encrypt for Department::FIN && Security Level::Low Secret when trying to encrypt for Department::FIN && Security Level::Top Secret.

Fix

The validity of the policy should be checked before each use. This could be done by signing the policy with the master secret key. This signature could be check using the public key.

Attack on the public key

Description

An attacker could trick a user into encrypting data for the wrong right (e.g. one the attacker is entitled to) by providing him with a modified public key.

For example, exchanging the value of a Security Level::Top Secret partition with the one of a Security Level::Low Secret partition in the public key HashMap would lead to actually encrypt for the later partition when trying to encrypt for former one.

Fix

The validity of the public key should be checked before each use. This could be done by signing the public key with the master secret key. This signature could be check using the public key.

tbrezot commented 1 year ago

The fix proposed to mitigate the attack on the public key involves using s1 or s2. This may not be secure as these keys are already use to derive the user secret keys.

An alternative fix would be to store a hash of the public key in the user secret keys. These hash would be protected from forgery by implementing the change proposed in #77. This would lead to increase the user keys by another 16 bytes. I would argue this is not an issue since this size increase is distributed among users and a central key management server could generate user keys on the fly if the number of user keys it has to store makes their size a problem.

The same fix could also be used to check the validity of the policy. Both could be done in the same time by implementing the change proposed in #97