| Message ID | 1492693983-8175-1-git-send-email-gilad@benyossef.com |
|---|---|
| Headers | show |
| Series | staging: ccree: add Arm TrustZone CryptoCell REE driver | expand |
On Thu, Apr 20, 2017 at 04:12:54PM +0300, Gilad Ben-Yossef wrote: > Arm TrustZone CryptoCell 700 is a family of cryptographic hardware > accelerators. It is supported by a long lived series of out of tree > drivers, which I am now in the process of unifying and upstreaming. > This is the first drop, supporting the new CryptoCell 712 REE. > > The code still needs some cleanup before maturing to a proper > upstream driver, which I am in the process of doing. However, > as discussion of some of the capabilities of the hardware and > its application to some dm-crypt and dm-verity features recently > took place I though it is better to do this in the open via the > staging tree. > > A Git repository based off of Linux 4.11-rc7 is also available at > https://github.com/gby/linux.git branch ccree_v2 for those inclined. If you want this in staging, I'll be glad to take it, but note then you can't work off of an external repo, as syncing the two is almost impossible and more work than you want to go through. So, as long as this builds properly, want me to queue these up in my tree? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Sonntag, 23. April 2017, 11:48:58 CEST schrieb Gilad Ben-Yossef: Hi Gilad, > I do wonder if there is value in alternate behavior of stopping crypto > API on FIPS error rather than a panic though. I will try to get an > explanation why we do it this way. In FIPS, all crypto function must cease if a self test fails. This can be done by instrumenting the crypto API calls with a check to a global flag or by simply terminating the entire "FIPS module". The panic() is the simplest approach to meet that requirement. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Apr 23, 2017 at 12:48 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote: > Hi, > > Thank you for the review. > > On Thu, Apr 20, 2017 at 4:39 PM, Stephan Müller <smueller@chronox.de> wrote: > >>> +/* The function verifies that tdes keys are not weak.*/ >>> +static int ssi_fips_verify_3des_keys(const u8 *key, unsigned int keylen) >>> +{ >>> +#ifdef CCREE_FIPS_SUPPORT >>> + tdes_keys_t *tdes_key = (tdes_keys_t*)key; >>> + >>> + /* verify key1 != key2 and key3 != key2*/ >> >> I do not think that this check is necessary. There is no FIPS requirement or >> IG that mandates this (unlike the XTS key check). >> >> If there would be such requirement, we would need a common service function >> for all TDES implementations Well, it turns out there is and we do :-) This is from crypto/des_generic.c: /* * RFC2451: * * For DES-EDE3, there is no known need to reject weak or * complementation keys. Any weakness is obviated by the use of * multiple keys. * * However, if the first two or last two independent 64-bit keys are * equal (k1 == k2 or k2 == k3), then the DES3 operation is simply the * same as DES. Implementers MUST reject keys that exhibit this * property. * */ int __des3_ede_setkey(u32 *expkey, u32 *flags, const u8 *key, unsigned int keylen) However, this does not check that k1 == k3. In this case DES3 becomes 2DES (2-keys TDEA), the use of which was dropped post 2015 by NIST Special Publication 800-131A*. Would it be acceptable if I offer a patch adding this check to __des3_ede_setkey() and use that in the ccree driver? * http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf Many thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Montag, 24. April 2017, 08:06:09 CEST schrieb Gilad Ben-Yossef: Hi Gilad, > > Well, it turns out there is and we do :-) > > This is from crypto/des_generic.c: > > /* > * RFC2451: > * > * For DES-EDE3, there is no known need to reject weak or > * complementation keys. Any weakness is obviated by the use of > * multiple keys. > * > * However, if the first two or last two independent 64-bit keys are > * equal (k1 == k2 or k2 == k3), then the DES3 operation is simply the > * same as DES. Implementers MUST reject keys that exhibit this > * property. > * > */ > int __des3_ede_setkey(u32 *expkey, u32 *flags, const u8 *key, > unsigned int keylen) > > However, this does not check that k1 == k3. In this case DES3 > becomes 2DES (2-keys TDEA), the use of which was dropped post 2015 > by NIST Special Publication 800-131A*. It is correct that the RFC wants at least a 2key 3DES. And it is correct that SP800-131A mandates 3key 3DES post 2015. All I am saying is that FIPS 140-2 does *not* require a technical verification of the 3 keys being not identical. Note, formally, FIPS 140-2 requires that the 3 keys (i.e. all 192 bits) must be obtained from *one* call to a DRBG or KDF (separate independent calls to, say, obtain one key at a time is *not* permitted). Of course, fixing the parity bits is allowed after obtaining the random number. > > Would it be acceptable if I offer a patch adding this check to > __des3_ede_setkey() > and use that in the ccree driver? I am not sure it makes sense as the core requirement is the *one* invocation of the DRBG. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Montag, 24. April 2017, 08:16:50 CEST schrieb Stephan Müller: Hi Gilad, > > > > int __des3_ede_setkey(u32 *expkey, u32 *flags, const u8 *key, > > > > unsigned int keylen) > > > > However, this does not check that k1 == k3. In this case DES3 > > becomes 2DES (2-keys TDEA), the use of which was dropped post 2015 > > by NIST Special Publication 800-131A*. > > It is correct that the RFC wants at least a 2key 3DES. And it is correct > that SP800-131A mandates 3key 3DES post 2015. All I am saying is that FIPS > 140-2 does *not* require a technical verification of the 3 keys being not > identical. One side note: we had discussed a patch to this function in the past, see [1]. [1] https://patchwork.kernel.org/patch/8293441/ Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Apr 24, 2017 at 9:21 AM, Stephan Müller <smueller@chronox.de> wrote: > Am Montag, 24. April 2017, 08:16:50 CEST schrieb Stephan Müller: > > Hi Gilad, > >> > >> > int __des3_ede_setkey(u32 *expkey, u32 *flags, const u8 *key, >> > >> > unsigned int keylen) >> > >> > However, this does not check that k1 == k3. In this case DES3 >> > becomes 2DES (2-keys TDEA), the use of which was dropped post 2015 >> > by NIST Special Publication 800-131A*. >> >> It is correct that the RFC wants at least a 2key 3DES. And it is correct >> that SP800-131A mandates 3key 3DES post 2015. All I am saying is that FIPS >> 140-2 does *not* require a technical verification of the 3 keys being not >> identical. > > One side note: we had discussed a patch to this function in the past, see [1]. > > [1] https://patchwork.kernel.org/patch/8293441/ > Thanks, I was not aware of that. I guess we could change the function to indicate that a key is valid for decryption but not encryption and have the implementation limiting based on that if there is an interest in SP800-131A compliance. Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Montag, 24. April 2017, 09:07:45 CEST schrieb Gilad Ben-Yossef: Hi Gilad, > I guess we could change the function to indicate that a key is valid > for decryption but not encryption > and have the implementation limiting based on that if there is an > interest in SP800-131A compliance. I would be delighted to see and review a patch. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Arm TrustZone CryptoCell 700 is a family of cryptographic hardware accelerators. It is supported by a long lived series of out of tree drivers, which I am now in the process of unifying and upstreaming. This is the first drop, supporting the new CryptoCell 712 REE. The code still needs some cleanup before maturing to a proper upstream driver, which I am in the process of doing. However, as discussion of some of the capabilities of the hardware and its application to some dm-crypt and dm-verity features recently took place I though it is better to do this in the open via the staging tree. A Git repository based off of Linux 4.11-rc7 is also available at https://github.com/gby/linux.git branch ccree_v2 for those inclined. Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com> CC: Binoy Jayan <binoy.jayan@linaro.org> CC: Ofir Drang <ofir.drang@arm.com> CC: Stuart Yoder <stuart.yoder@arm.com> Changes from v1: - Broke up patch set into smaller units for mailing list review as per Greg KH's indication. - Changed DT binding compatible tag as per Mark Rutland suggestion. - Moved DT binding document inside the staging directory and added DT binding review to TODO list as per Mark Rutland's request. Many thanks to all reviewers :-) Gilad Ben-Yossef (9): staging: ccree: introduce CryptoCell HW driver staging: ccree: add ahash support staging: ccree: add skcipher support staging: ccree: add IV generation support staging: ccree: add AEAD support staging: ccree: add FIPS support staging: ccree: add TODO list staging: ccree: add DT bindings for Arm CryptoCell MAINTAINERS: add Gilad BY as ccree maintainer MAINTAINERS | 7 + drivers/staging/Kconfig | 2 + drivers/staging/Makefile | 2 +- .../devicetree/bindings/crypto/arm-cryptocell.txt | 27 + drivers/staging/ccree/Kconfig | 43 + drivers/staging/ccree/Makefile | 3 + drivers/staging/ccree/TODO | 28 + drivers/staging/ccree/bsp.h | 21 + drivers/staging/ccree/cc_bitops.h | 62 + drivers/staging/ccree/cc_crypto_ctx.h | 299 +++ drivers/staging/ccree/cc_hal.h | 35 + drivers/staging/ccree/cc_hw_queue_defs.h | 603 +++++ drivers/staging/ccree/cc_lli_defs.h | 57 + drivers/staging/ccree/cc_pal_log.h | 188 ++ drivers/staging/ccree/cc_pal_log_plat.h | 33 + drivers/staging/ccree/cc_pal_types.h | 97 + drivers/staging/ccree/cc_pal_types_plat.h | 29 + drivers/staging/ccree/cc_regs.h | 106 + drivers/staging/ccree/dx_crys_kernel.h | 180 ++ drivers/staging/ccree/dx_env.h | 224 ++ drivers/staging/ccree/dx_host.h | 155 ++ drivers/staging/ccree/dx_reg_base_host.h | 34 + drivers/staging/ccree/dx_reg_common.h | 26 + drivers/staging/ccree/hash_defs.h | 78 + drivers/staging/ccree/hw_queue_defs_plat.h | 43 + drivers/staging/ccree/ssi_aead.c | 2832 ++++++++++++++++++++ drivers/staging/ccree/ssi_aead.h | 120 + drivers/staging/ccree/ssi_buffer_mgr.c | 1876 +++++++++++++ drivers/staging/ccree/ssi_buffer_mgr.h | 105 + drivers/staging/ccree/ssi_cipher.c | 1503 +++++++++++ drivers/staging/ccree/ssi_cipher.h | 89 + drivers/staging/ccree/ssi_config.h | 61 + drivers/staging/ccree/ssi_driver.c | 557 ++++ drivers/staging/ccree/ssi_driver.h | 228 ++ drivers/staging/ccree/ssi_fips.c | 65 + drivers/staging/ccree/ssi_fips.h | 70 + drivers/staging/ccree/ssi_fips_data.h | 315 +++ drivers/staging/ccree/ssi_fips_ext.c | 96 + drivers/staging/ccree/ssi_fips_ll.c | 1681 ++++++++++++ drivers/staging/ccree/ssi_fips_local.c | 369 +++ drivers/staging/ccree/ssi_fips_local.h | 77 + drivers/staging/ccree/ssi_hash.c | 2751 +++++++++++++++++++ drivers/staging/ccree/ssi_hash.h | 101 + drivers/staging/ccree/ssi_ivgen.c | 301 +++ drivers/staging/ccree/ssi_ivgen.h | 72 + drivers/staging/ccree/ssi_pm.c | 150 ++ drivers/staging/ccree/ssi_pm.h | 46 + drivers/staging/ccree/ssi_pm_ext.c | 60 + drivers/staging/ccree/ssi_pm_ext.h | 33 + drivers/staging/ccree/ssi_request_mgr.c | 713 +++++ drivers/staging/ccree/ssi_request_mgr.h | 60 + drivers/staging/ccree/ssi_sram_mgr.c | 138 + drivers/staging/ccree/ssi_sram_mgr.h | 80 + drivers/staging/ccree/ssi_sysfs.c | 440 +++ drivers/staging/ccree/ssi_sysfs.h | 54 + 55 files changed, 17424 insertions(+), 1 deletion(-) create mode 100644 drivers/staging/ccree/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt create mode 100644 drivers/staging/ccree/Kconfig create mode 100644 drivers/staging/ccree/Makefile create mode 100644 drivers/staging/ccree/TODO create mode 100644 drivers/staging/ccree/bsp.h create mode 100644 drivers/staging/ccree/cc_bitops.h create mode 100644 drivers/staging/ccree/cc_crypto_ctx.h create mode 100644 drivers/staging/ccree/cc_hal.h create mode 100644 drivers/staging/ccree/cc_hw_queue_defs.h create mode 100644 drivers/staging/ccree/cc_lli_defs.h create mode 100644 drivers/staging/ccree/cc_pal_log.h create mode 100644 drivers/staging/ccree/cc_pal_log_plat.h create mode 100644 drivers/staging/ccree/cc_pal_types.h create mode 100644 drivers/staging/ccree/cc_pal_types_plat.h create mode 100644 drivers/staging/ccree/cc_regs.h create mode 100644 drivers/staging/ccree/dx_crys_kernel.h create mode 100644 drivers/staging/ccree/dx_env.h create mode 100644 drivers/staging/ccree/dx_host.h create mode 100644 drivers/staging/ccree/dx_reg_base_host.h create mode 100644 drivers/staging/ccree/dx_reg_common.h create mode 100644 drivers/staging/ccree/hash_defs.h create mode 100644 drivers/staging/ccree/hw_queue_defs_plat.h create mode 100644 drivers/staging/ccree/ssi_aead.c create mode 100644 drivers/staging/ccree/ssi_aead.h create mode 100644 drivers/staging/ccree/ssi_buffer_mgr.c create mode 100644 drivers/staging/ccree/ssi_buffer_mgr.h create mode 100644 drivers/staging/ccree/ssi_cipher.c create mode 100644 drivers/staging/ccree/ssi_cipher.h create mode 100644 drivers/staging/ccree/ssi_config.h create mode 100644 drivers/staging/ccree/ssi_driver.c create mode 100644 drivers/staging/ccree/ssi_driver.h create mode 100644 drivers/staging/ccree/ssi_fips.c create mode 100644 drivers/staging/ccree/ssi_fips.h create mode 100644 drivers/staging/ccree/ssi_fips_data.h create mode 100644 drivers/staging/ccree/ssi_fips_ext.c create mode 100644 drivers/staging/ccree/ssi_fips_ll.c create mode 100644 drivers/staging/ccree/ssi_fips_local.c create mode 100644 drivers/staging/ccree/ssi_fips_local.h create mode 100644 drivers/staging/ccree/ssi_hash.c create mode 100644 drivers/staging/ccree/ssi_hash.h create mode 100644 drivers/staging/ccree/ssi_ivgen.c create mode 100644 drivers/staging/ccree/ssi_ivgen.h create mode 100644 drivers/staging/ccree/ssi_pm.c create mode 100644 drivers/staging/ccree/ssi_pm.h create mode 100644 drivers/staging/ccree/ssi_pm_ext.c create mode 100644 drivers/staging/ccree/ssi_pm_ext.h create mode 100644 drivers/staging/ccree/ssi_request_mgr.c create mode 100644 drivers/staging/ccree/ssi_request_mgr.h create mode 100644 drivers/staging/ccree/ssi_sram_mgr.c create mode 100644 drivers/staging/ccree/ssi_sram_mgr.h create mode 100644 drivers/staging/ccree/ssi_sysfs.c create mode 100644 drivers/staging/ccree/ssi_sysfs.h -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html