Changes between Version 12 and Version 13 of linux/encryption

10/26/2021 11:13:37 PM (2 years ago)
Ryan Erbstoesser

add security notes


  • linux/encryption

    v12 v13  
    436436  - OpenWrt - cryptodev
    437437  - Yocto - cryptodev
     439= Some Security Thoughts
     441The below is simply some thoughts for implementing security / encryption on the Gateworks SBCs:
     443Linux full disk encryption can be provided by the dm-crypt kernel
     444driver/module and file or file-system based encryption can be provided
     445by the fscrypt or eCryptFS projects. All of these solutions require a
     446key used to crypt/decrypt. Additionally, the kernel itself can't mount
     447a root filesystem that uses encryption so initrd's (initial ramdisk)
     448are used for this such that a ramdisk filesystem is built into the
     449kernel with enough support to do the encrypted device/file/fielsystem
     452As far as keys are concerned you can either use symmetric keys which
     453crypt/decrypt is the same key, or asymmetric keys where crypt/decrypt
     454keys are different (priv/pub RSA keys for example). On
     455desktop/smarphone the key used to encrypt the filesystem could be
     456derived from a user password/passphrase entered interactively (which
     457is how Android phone encryption works for example). On an embedded
     458system without user interaction the key 'should' be stored encrypted
     459in the filesystem or in secure storage (such as a TPM). This isn't a
     460requirement but then what is the point of encrypting something if a
     461hacker can exploit some security hole and end up finding the key?
     463Note that i.MX SoC's have a Hardware Unique Key (HUK) per chip that
     464can be accessed only by the IMX Cryptographic and Assurance Module
     465(CAAM). This HUK can be used to encrypt a key and store it in the
     466filesystem during manufacturing. During boot CAAM would be used to
     467decrypt the key and restore the plain key that would be used to
     468decrypt the filesystem. Since the key inside CAAM is not accessible
     469the encrypted key is always protected.
     471You could also use external hardware like a Secure Element or a TPM
     472device which usually provide secure storage that could be used to
     473store a master key that could be used to encrypt/decrypt a filesystem
     474encryption key.
     476Another alternative is a Trusted Execution Environment (TEE) where the
     477code executed and the data accessed is isolated and protected in terms
     478of confidentiality (nobody has access to the data) and integrity
     479(nobody can change the code and its behavior). This is discussed here:
     482Note also that if you are going to use encryption you had better be
     483using secure boot as well otherwise as mentioned a hacker could easily
     484insert their own code to invalidate any encryption that is done.
     485Encrypted boot on top of secure boot is also an option but if you are
     486using a TPM device (or IMX CAAM) the keys are protected and therefore
     487encrypted boot firmware may not really be necessary.
     489These topics are extremely complex and unique to each customer. The customer can implement these or there are
     490companies that specialize in such services.
     492Our top customers
     493understand security needs and are following this path with their own
     494software resources:
     495 - One customer is using secure boot but did not see the need for 'encrypted boot' where their boot firmware is also encrypted. They are encrypting 'something' that they didn't disclose but we believe its at the filesystem level and they are using the CAAM for key storage via some U-Boot and Linux provided. Consider this possibly could have been done more easily by using a TEE.
     496 - Another customer is contracting Canonical for Ubuntu Core support and Canonical uses disk encryption and a TEE
     497 - Another customer is planning on using Secure Boot with Newport