Re: Oopsing cryptoapi (or loop device?) on 2.6.*

[Jari Ruusu]

Jan Rychter wrote:
> And, just wondering -- if loop-AES works so much better, why hasn't it
> been included in the kernel?

Because I stopped wasting my time with mainline kernels long time ago, and
because mainline folks seemed to prefer the most vulnerable loop crypto
implementation they could find (i.e. cryptoloop).

Just look at mainline folks merging another equally vulnerable and exploitable
implementation (i.e. dm-crypt), with exactly same vulnerabilities that
cryptoloop has, just in different package.

In loop-AES, "bad key management" issues were fixed years ago, and more
stronger IV was merged last year. Mainline folks still seem to be
puzzled/clueless with these issues.

-

Markku-Juhani O. Saarinen discovered watermark attack against cryptoloop,
here is his paper:

    http://www.tcs.hut.fi/~mjos/doc/diskenc.pdf

[just before posting I tested above link and it returns "You don't have
permission to access /~mjos/doc/diskenc.pdf on this server", ugh]

This attack exploits weakness in IV computation and knowledge of how file
systems place files on disk. This attack works with file systems that have
soft block size of 1024 or greater. At least ext2, ext3, reiserfs and minix
have such property. Don't know about xfs. This attack makes it possible to
detect presense of specially crafted watermarked files, such as, unreleased
Hollywood movies, cruise missile service manuals, and other content that you
did not create yourself. Watermarked files contain special bit patterns that
can be detected without decryption.

I have attached source for two programs, one to create such watermarked
files, and one to detect watermarks from ciphertext.

For example, if I were to encode my first name Jari as a watermark, I would
use ASCII characters 74 97 114 105. This example uses encodings 10...13.

    # mount -t ext2 /dev/fd0 /mnt -o loop=/dev/loop0,encryption=AES128
    Password:
    # ./create-watermark-encodings 10:74 11:97 12:114 13:105 >/mnt/watermarks
    # umount /mnt

And then to detect these watermarks, I do:

    # dd if=/dev/fd0 bs=64k | ./detect-watermark-encodings
    22+1 records in
    22+1 records out
    1474560 bytes scanned
    watermark encoding 10, count 74
    watermark encoding 11, count 97
    watermark encoding 12, count 114
    watermark encoding 13, count 105
    
Summary:
- cryptoloop and dm-crypt on-disk formats are FUBAR. cryptoloop and
  dm-crypto developers and users don't have any choice here. The _have_ to
  start using stronger crypto.
- Used cipher or key kength or password does not matter.
- loop-AES single-key mode on-disk format is equally FUBAR.  
- loop-AES multi-key mode is not vulnerable.
- Anyone still setting up new encrypted file systems using cryptoloop or
  current dm-crypt or single-key loop-AES, is committing security
  malpractice.

-- 
Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD

Attachment: cryptoloop-exploit.tar.bz2
Description: Binary data