Re: Vulnerability in encrypted loop device for linux

[Alfonso De Gregorio <agregorio () acm org>]

Hi Jerome, hi Everyone,

> The following text describes a security hole in the encrypted loop 
> device for Linux. Because of it, an attacker is able to modify the 
> content of the encrypted device without being detected. This text 
> proposes to fix the hole by authenticating the device.
>
> comments are welcome

Correct. The encrypted loop device for Linux is vulnerable to the 
described attack.

However, I'd rather prefer, in certain contexts, the use of a digital 
signature scheme to HMAC, while authenticating especially at mount time
and sometimes at cluster time, for the following reasons (in no
particular order):

0 digital signature schemes allows administrator(s) of each system to 
  trust or not to trust colleagues, while not sharing the same HMAC 
  secret key;
0 digital signature can be "safely" computed by external well-known 
  crypto hardware (eg. smart cards, coprocessors, etc.);
0 the same technology can be used to produce signature(s) for optical 
  storage, as required by some national directives (eg. such as the 
  Italian one that actually require two signatures and two hash computed
  with different hash algorithms);
0 the administration pool can choose to not trust anymore the contents 
  of an encrypted device signed with a key-pair owned by an administrator
  that has been revoked from the pool (eg. an administrator can be 
  fired, etc.);
0 time-stamp tokens [RFC 3161] allows the pool of administrators to 
  continue to trust the contents of an encrypted device signed before 
  the revocation of the signing key-pair;
0 etc.

The trade-off between the security and the efficiency offered by a digital 
signature scheme is in my opinion acceptable especially while using the 
device for non interactive purposes; I'm thinking to WORM used 
for archiving data (in this context the authentication token can be 
computed not only for each file but can come either at cluster time or 
when the WORM disk get closed).

Sincerely,
alfonso

[RFC 3161] Internet X.509 Public Key Infrastructure Time-Stamp
                Protocol (TSP) - C. Adams, P. Cain, D. Pinkas, 
                R. Zuccherato - <http://www.ietf.org/rfc/rfc3161.txt>