Dmitry Monakhov <dmonlist@xxxxxxxxx> writes: > Theodore Ts'o <tytso@xxxxxxx> writes: > >> On Wed, May 27, 2015 at 01:06:06PM -0400, Theodore Ts'o wrote: >>> >>> That's not true. If the attacker finds the encryption key for an >>> inode, and they have the nonce which is stored in file's extended >>> attribute, what the attacker has is a single plaintext/ciphertext >>> pair. That doesn't imply that they can get the master key; they would >>> still need to do a brute force search on the keyspace try to find the >>> master key. >> >> So an update, after conferring with Michael Halcrow, who set me >> straight. I was wrong, because I mixed up which was the deriving key >> and which was the source key. You're correct; if an attacker could >> get ahold of the per-file key, they could use the nonce to decrypt it >> and obtain the master key. >> >> However, there are only two ways to determine the per-file key. The >> first is a ring 0 compromise, in which case it's likely they could get >> access to the master key, and the second is if there is a practical >> known-plaintext attack on AES, and the attacker has access to the >> block device --- and possibly a chosen-plaintext attack if the >> attacker can control what data is written to the file. But either >> way, if there is such a crypto-analytic attack on AES, then this is >> going to be least of the whole world's problems. :-) > Ohh. My knowledge in cryptography is very weak, but imagine same > practical scenarios where attacker can find dozens of files with > known content by using knowledge of inode attributes and environment. > Let's consider user encrypted his encrypted chroot-environment, so > attacker may try to compare file attributes (permission, size and > directory nesting level) with files from distro repositories (rpm/deb) > > For example let's comare two directories encrypted one and my /bin/ > kvm-xfstests:~# ls -l /vdc/X/4BbchaihxJLF5D+gErB0DC/ | sort -k 5 > -n | tail - > -rwxr-xr-x 1 root root 202936 May 29 17:09 l51q60ZbBvtGnUl8a3y3yA > -rwxr-xr-x 1 root root 219392 May 29 17:09 5NluBcuHcBAb6J6ByLUtBC > -rwxr-xr-x 1 root root 235768 May 29 17:09 lrFAT0jlaLHwenJ2PqwiEA > -rwxr-xr-x 1 root root 290816 May 29 17:09 P7A5KsxbBO4Dyv8ofxedhA > -rwxr-xr-x 1 root root 309488 May 29 17:09 PeOSBWm54qDpEMCov6TqSC > -rwxr-xr-x 1 root root 313584 May 29 17:09 TEGrdRgB2KxMFqysRtg6LB > -rwxr-xr-x 1 root root 314560 May 29 17:09 e6waVwHbgdmx97A,CncgxD > -rwxr-xr-x 1 root root 358072 May 29 17:09 Zz51PHoSv91wjUjn9sCypB > -rwxr-xr-x 1 root root 538904 May 29 17:09 ulVnXayZZW0SdYp3fJe83B > root@kvm-xfstests:~# ls -l /bin | sort -k 5 -n | tail -n10 > -rwxr-xr-x 1 root root 202936 Oct 3 2014 grep > -rwxr-xr-x 1 root root 219392 Dec 5 09:13 journalctl > -rwxr-xr-x 1 root root 235768 Dec 5 09:13 systemd-inhibit > -rwxr-xr-x 1 root root 280816 Dec 5 09:13 machinectl > -rwxr-xr-x 1 root root 309488 Dec 5 09:13 loginctl > -rwxr-xr-x 1 root root 313584 Dec 5 09:13 udevadm > -rwxr-xr-x 1 root root 314560 Sep 5 2014 ip > -rwxr-xr-x 1 root root 358072 Nov 8 2014 tar > -rwxr-xr-x 1 root root 538904 Dec 5 09:13 systemctl > -rwxr-xr-x 1 root root 1029624 Nov 12 2014 bash > > This gives me as an attacker very good guess that > l51q60ZbBvtGnUl8a3y3yA == grep and so on, So I have can try brute force > attack on first block (But AFAIU it is not practical for AES-256) > May be we can prevent this my tweak inode size if key is not > available. For example allign i_size to fsblock which makes distro-based > attack impractical. See patch attached. > >> >> There are alternatives, such as either using the master to encrypt the >> nonce and none+1: (AES-256-ENCRYPT(nonce) || AES-256-ENCRYPT >> (nonce+1)). But this will be 40% slower than what we are currently >> doing, which is to use AES-256 to encrypt the master key. >> > At least it would be reasonable to provide this as an mkfs/tune2fs > option. I'll try to prepare patches. >> Or we could use an HMAC, which would be even slower yet, especially >> since many chips have AES acceleration, but few have SHA hardware >> acceleration. >> >> So ultimately, the question is whether we want to make a change (with >> all of the versioning work we would need for backwards compatibility) >> that decreases performance, which will be especially noticeable for >> small files, to protect against a partial Ring 0 compromise when other >> Ring 0 compromise would make us be toast anyway. >> >> - Ted > > diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c > index 0554b0b..e45cec4 100644 > --- a/fs/ext4/inode.c > +++ b/fs/ext4/inode.c > @@ -4790,6 +4790,10 @@ int ext4_getattr(struct vfsmount *mnt, struct dentry *dentry, > inode = d_inode(dentry); > generic_fillattr(inode, stat); > > + /* Tweak inode size for encrypted inodes */ > + if (unlikely(ext4_encrypted_inode(inode) && ext4_get_encryption_info(inode) == -ENOKEY)) > + stat->size = (stat->size + stat->blksize - 1 ) & ~(stat->blksize - 1); > + Hm. I've just realized that this patch is useless because once attacker has access to FS he likely also has access to block device so i_size is known for each inode because it is stored on disk unencrypted. > /* > * If there is inline data in the inode, the inode will normally not > * have data blocks allocated (it may have an external xattr block). -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
