1. 19 Dec, 2014 1 commit
  2. 18 Dec, 2014 6 commits
  3. 13 Dec, 2014 3 commits
  4. 02 Dec, 2014 8 commits
  5. 21 Nov, 2014 4 commits
    • Iliyan Malchev's avatar
      am bb7d9afe: fall back to dm-crypt if device already encrypted · c9c51717
      Iliyan Malchev authored
      * commit 'bb7d9afe':
        fall back to dm-crypt if device already encrypted
      c9c51717
    • Iliyan Malchev's avatar
      resolved conflicts for merge of 87701e27 to lmp-mr1-dev-plus-aosp · b7d35115
      Iliyan Malchev authored
      Change-Id: Ie873baff626fe786515497f2e81aa9db2329168d
      b7d35115
    • Iliyan Malchev's avatar
      fall back to dm-crypt if device already encrypted · bb7d9afe
      Iliyan Malchev authored
      
      Devices already encrypted with aes-cbc-essiv:sha256 will continue to be
      decrypted in software, until a factory data reset.  New devices that
      implement CONFIG_HW_DISK_ENCRYPTION will switch to aes-xts.
      
      b/17475056 Enable hardware crypto for userdata encryption
      
      Change-Id: I62d1583bdaf7ff06b87e386e758fa3b18c719bca
      Signed-off-by: default avatarIliyan Malchev <malchev@google.com>
      bb7d9afe
    • Ajay Dudani's avatar
      Adding support of dm-req-crypt · 87701e27
      Ajay Dudani authored
      
      Currently Android provides disk encryption support using dm-crypt
      which is based on bios. dm-crypt uses 512 bytes packet size for
      crypto operations. While 512 bytes size packet is ok for SW based
      disk encryption, it is inefficient for HW based crypto engines.
      dm-req-crypt is similar to dm-crypt except it uses block requests
      rathe bios for crypto operations. block requests when unpacked
      carries data upto 512KB. Hence, HW based crypto engine can be used
      more efficiently.
      
      Also move create disk encryption key before framework start as
      HW based disk encryption creates key in secure side. Key creation
      can take sometime to create the key securely. If framework is
      started before creating the key, it is possible that framework
      requests service from secure side. Secure side can serve mostly one
      request at a time. Secure side may reject framework request if key
      creation request is still going on. This may cause problem in the
      system
      
      b/17475056 Enable hardware crypto for userdata encryption
      
      Change-Id: I5480ab72a37c02532218a18faaba598a824589fd
      Signed-off-by: default avatarIliyan Malchev <malchev@google.com>
      87701e27
  6. 06 Nov, 2014 5 commits
  7. 05 Nov, 2014 2 commits
  8. 04 Nov, 2014 1 commit
    • Shawn Willden's avatar
      Modify vold to check for hardware keymaster. · 7c49ab0a
      Shawn Willden authored
      vold should only use hardware keymaster implementations to protect the
      disk encryption key, because there's little value in using the software
      implementation.  More importantly, if we allow vold to use softkeymaster
      in the absence of a HW keymaster and (somehow) a HW keymaster is added
      to a device, the HW version will be loaded, and will be unable to use
      the softkeymaster key found in the crypto footer, forcing a factory
      reset.
      
      This CL will not break devices without HW keymaster, because
      softkeymaster currently reports its keys as non-standalone (which isn't
      correct).  After this CL is in, I will fix softkeymaster.
      
      Bug: 17362157
      Change-Id: I98b169e7a59ff7d44b72069b87743463ec823ea2
      7c49ab0a
  9. 30 Oct, 2014 1 commit
  10. 29 Oct, 2014 9 commits