Changes between Version 12 and Version 13 of linux/encryption

Timestamp:

10/26/2021 11:13:37 PM (3 years ago)

Author:

Ryan Erbstoesser

Comment:

add security notes

linux/encryption

@@ -436 +436 @@
   - OpenWrt - cryptodev
   - Yocto - cryptodev
+
+= Some Security Thoughts
+
+The below is simply some thoughts for implementing security / encryption on the Gateworks SBCs:
+
+Linux full disk encryption can be provided by the dm-crypt kernel
+driver/module and file or file-system based encryption can be provided
+by the fscrypt or eCryptFS projects. All of these solutions require a
+key used to crypt/decrypt. Additionally, the kernel itself can't mount
+a root filesystem that uses encryption so initrd's (initial ramdisk)
+are used for this such that a ramdisk filesystem is built into the
+kernel with enough support to do the encrypted device/file/fielsystem
+mounting.
+
+As far as keys are concerned you can either use symmetric keys which
+crypt/decrypt is the same key, or asymmetric keys where crypt/decrypt
+keys are different (priv/pub RSA keys for example). On
+desktop/smarphone the key used to encrypt the filesystem could be
+derived from a user password/passphrase entered interactively (which
+is how Android phone encryption works for example). On an embedded
+system without user interaction the key 'should' be stored encrypted
+in the filesystem or in secure storage (such as a TPM). This isn't a
+requirement but then what is the point of encrypting something if a
+hacker can exploit some security hole and end up finding the key?
+
+Note that i.MX SoC's have a Hardware Unique Key (HUK) per chip that
+can be accessed only by the IMX Cryptographic and Assurance Module
+(CAAM). This HUK can be used to encrypt a key and store it in the
+filesystem during manufacturing. During boot CAAM would be used to
+decrypt the key and restore the plain key that would be used to
+decrypt the filesystem. Since the key inside CAAM is not accessible
+the encrypted key is always protected.
+
+You could also use external hardware like a Secure Element or a TPM
+device which usually provide secure storage that could be used to
+store a master key that could be used to encrypt/decrypt a filesystem
+encryption key.
+
+Another alternative is a Trusted Execution Environment (TEE) where the
+code executed and the data accessed is isolated and protected in terms
+of confidentiality (nobody has access to the data) and integrity
+(nobody can change the code and its behavior). This is discussed here:
+[wiki:venice/tee]
+
+Note also that if you are going to use encryption you had better be
+using secure boot as well otherwise as mentioned a hacker could easily
+insert their own code to invalidate any encryption that is done.
+Encrypted boot on top of secure boot is also an option but if you are
+using a TPM device (or IMX CAAM) the keys are protected and therefore
+encrypted boot firmware may not really be necessary.
+
+These topics are extremely complex and unique to each customer. The customer can implement these or there are
+companies that specialize in such services. 
+
+Our top customers
+understand security needs and are following this path with their own
+software resources:
+ - 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.
+ - Another customer is contracting Canonical for Ubuntu Core support and Canonical uses disk encryption and a TEE 
+ - Another customer is planning on using Secure Boot with Newport