Skip to content
Snippets Groups Projects
Select Git revision
0 results
Search by author
  • Any Author
0 authors
  1. Dec 05, 2017
  3. Oct 06, 2017
  5. Aug 09, 2017
  7. Jul 07, 2017
  9. Feb 22, 2017
    • Daniel Rosenberg's avatar
      ANDROID: sdcardfs: Don't bother deleting freelist · 880c68e4
      Daniel Rosenberg authored 
      
There is no point deleting entries from dlist, as
that is a temporary list on the stack from which
contains only entries that are being deleted.

Not all code paths set up dlist, so those that
don't were performing invalid accesses in
hash_del_rcu. As an additional means to prevent
any other issue, we null out the list entries when
we allocate from the cache.

Signed-off-by: default avatarDaniel Rosenberg <drosen@google.com>
Bug: 35666680
Change-Id: Ibb1e28c08c3a600c29418d39ba1c0f3db3bf31e5
      880c68e4
  11. Feb 17, 2017
  13. Feb 15, 2017
  15. Feb 14, 2017
    • Michael Halcrow's avatar
      ANDROID: ext4 crypto: Disables zeroing on truncation when there's no key · 8b75db98
      Michael Halcrow authored 
      
When performing orphan cleanup on mount, ext4 may truncate pages.
Truncation as currently implemented may require the encryption key for
partial zeroing, and the key isn't necessarily available on mount.
Since the userspace tools don't perform the partial zeroing operation
anyway, let's just skip doing that in the kernel.

This patch fixes a BUG_ON() oops.

Bug: 35209576
Change-Id: I2527a3f8d2c57d2de5df03fda69ee397f76095d7
Signed-off-by: default avatarMichael Halcrow <mhalcrow@google.com>
      8b75db98
  17. Feb 10, 2017
    • Eric Biggers's avatar
      ANDROID: ext4: add a non-reversible key derivation method · a425a70b
      Eric Biggers authored 
      
Add a new per-file key derivation method to ext4 encryption defined as:

    derived_key[0:127]   = AES-256-ENCRYPT(master_key[0:255], nonce)
    derived_key[128:255] = AES-256-ENCRYPT(master_key[0:255], nonce ^ 0x01)
    derived_key[256:383] = AES-256-ENCRYPT(master_key[256:511], nonce)
    derived_key[384:511] = AES-256-ENCRYPT(master_key[256:511], nonce ^ 0x01)

... where the derived key and master key are both 512 bits, the nonce is
128 bits, AES-256-ENCRYPT takes the arguments (key, plaintext), and
'nonce ^ 0x01' denotes flipping the low order bit of the last byte.

The existing key derivation method is
'derived_key = AES-128-ECB-ENCRYPT(key=nonce, plaintext=master_key)'.
We want to make this change because currently, given a derived key you
can easily compute the master key by computing
'AES-128-ECB-DECRYPT(key=nonce, ciphertext=derived_key)'.

This was formerly OK because the previous threat model assumed that the
master key and derived keys are equally hard to obtain by an attacker.
However, we are looking to move the master key into secure hardware in
some cases, so we want to make sure that an attacker with access to a
derived key cannot compute the master key.

We are doing this instead of increasing the nonce to 512 bits because
it's important that the per-file xattr fit in the inode itself.  By
default, inodes are 256 bytes, and on Android we're already pretty close
to that limit. If we increase the nonce size, we end up allocating a new
filesystem block for each and every encrypted file, which has a
substantial performance and disk utilization impact.

Another option considered was to use the HMAC-SHA512 of the nonce, keyed
by the master key.  However this would be a little less performant,
would be less extensible to other key sizes and MAC algorithms, and
would pull in a dependency (security-wise and code-wise) on SHA-512.

Due to the use of "aes" rather than "ecb(aes)" in the implementation,
the new key derivation method is actually about twice as fast as the old
one, though the old one could be optimized similarly as well.

This patch makes the new key derivation method be used whenever HEH is
used to encrypt filenames.  Although these two features are logically
independent, it was decided to bundle them together for now.  Note that
neither feature is upstream yet, and it cannot be guaranteed that the
on-disk format won't change if/when these features are upstreamed.  For
this reason, and as noted in the previous patch, the features are both
behind a special mode number for now.

Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
Change-Id: Iee4113f57e59dc8c0b7dc5238d7003c83defb986
      a425a70b