Re: [RFC 2/4] Add rsa support
On 16:42 Mon 16 Mar , Jan Lübbe wrote: On Mo, 2015-03-16 at 12:33 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: I do not like and do not want to use the FTD format to store the key but x509. Yes, I think we are in agreement that we need to support both key formats. Image format need to be 100% seperated from key format. Of course. That's why I work on a framework so we do not care of both. Multiple image format with multiple image of key format. Could you explain your image format in a bit more detail? How your intend to defend against a mix-and-match attack? One of the format we are using can only be one configure signed or/and encrypted so no mix-and-match attack Best Regards, J. Regards, Jan -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [RFC 2/4] Add rsa support
On 13:09 Tue 17 Mar , Jan Lübbe wrote: Hi Jean-Christophe, On Di, 2015-03-17 at 11:48 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: Could you explain your image format in a bit more detail? How your intend to defend against a mix-and-match attack? One of the format we are using can only be one configure signed or/and encrypted so no mix-and-match attack Sorry, it's still not clear to me. Do you mean you would use FIT in that case (it supports signed configurations)? Or do you mean that you are using several formats, one of which uses signed/encrypted configurations of kernel/initramfs/dt? yes sevral format FIT is just one of them I want to understand how your image formats would be used in the larger context of a BSP or distribution. Please describe which image formats you want to support (in addition to FIT). How are they structured? How are they generated? Are they already supported by other software? Today we use a bpk formoat in bpk format you can store different data for each hw_id, each data have a specific type. we add a new type for the signature. we do a sha512 of the other data of one hw_id and signed it with a rsa4096 we use 1 unique rsa key per HW_ID as soon as one of the file of a specific hw_id is open we check the signature The code is no public yet but this is handled at FS level and we allow only to open data that have been verified or decrypted if we use AES Best Regards, J. ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [RFC 2/4] Add rsa support
Hi Jean-Christophe, On Di, 2015-03-17 at 11:48 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: Could you explain your image format in a bit more detail? How your intend to defend against a mix-and-match attack? One of the format we are using can only be one configure signed or/and encrypted so no mix-and-match attack Sorry, it's still not clear to me. Do you mean you would use FIT in that case (it supports signed configurations)? Or do you mean that you are using several formats, one of which uses signed/encrypted configurations of kernel/initramfs/dt? I want to understand how your image formats would be used in the larger context of a BSP or distribution. Please describe which image formats you want to support (in addition to FIT). How are they structured? How are they generated? Are they already supported by other software? Thanks, Jan -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [RFC 2/4] Add rsa support
On Di, 2015-03-17 at 13:39 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: I want to understand how your image formats would be used in the larger context of a BSP or distribution. Please describe which image formats you want to support (in addition to FIT). How are they structured? How are they generated? Are they already supported by other software? Today we use a bpk formoat in bpk format you can store different data for each hw_id, each data have a specific type. we add a new type for the signature. we do a sha512 of the other data of one hw_id and signed it with a rsa4096 we use 1 unique rsa key per HW_ID as soon as one of the file of a specific hw_id is open we check the signature The code is no public yet but this is handled at FS level and we allow only to open data that have been verified or decrypted if we use AES Thanks for the explanation, it's clearer now. Regards, Jan -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [RFC 2/4] Add rsa support
On Mo, 2015-03-16 at 11:27 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 11:00 Mon 16 Mar , Jan Lübbe wrote: On Fr, 2015-03-13 at 16:49 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: you just need to have a unique ID on the HW and then use a x509 object to store it. then signed it with you CA. As only validated keys can be used, you can easly give a generated key for a specific HW. And this key will be valid only for this HW. Yes, this sounds useful. So you'd have a board-specific way to check the unique ID constraint in an intermediate cert against the HW ID? yes more or less but but at the key itself as you will have to upload the key to the board. And the key will only be accepted to be stored as it will be valid and have the HW ID. OK. Sounds good to me. And for the record remember if you want to use module in secured boot mode for the kernel you will have to use x509 certificate anyway. So why not to use the same principal. u-boot way is not what is doing today on the market for authentication format. Today it's x509 or PGP. So I do prefer to stay as standard as possible, this does not mean we can not support the FTD stuff. But IMHO it's not the right way. x509 only defines the certificate format, not how it is used to sign kernel, initramfs and device tree. The kernel defines its own format based on ELF and store the signature inside. That can't be reused directly for the kernel itself, initramfs or DTB. UEFI has again its own format. We don't want to sign kernel, initramfs and DTB individually, as this would allow an attacker to mix-and-match these to trigger a vulnerability. So we need to have some format which supports signing a given configuration consisting of specific kernel, initramfs and DTB. FIT handles this requirement. It also supports having multiple configurations (each signed) referencing for example the same kernel +initramfs but different DTBs for a set of similar boards. What is the image format you intend to use with x509 certs? Regards, Jan -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [RFC 2/4] Add rsa support
On 12:25 Mon 16 Mar , Jan Lübbe wrote: On Mo, 2015-03-16 at 11:27 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 11:00 Mon 16 Mar , Jan Lübbe wrote: On Fr, 2015-03-13 at 16:49 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: you just need to have a unique ID on the HW and then use a x509 object to store it. then signed it with you CA. As only validated keys can be used, you can easly give a generated key for a specific HW. And this key will be valid only for this HW. Yes, this sounds useful. So you'd have a board-specific way to check the unique ID constraint in an intermediate cert against the HW ID? yes more or less but but at the key itself as you will have to upload the key to the board. And the key will only be accepted to be stored as it will be valid and have the HW ID. OK. Sounds good to me. And for the record remember if you want to use module in secured boot mode for the kernel you will have to use x509 certificate anyway. So why not to use the same principal. u-boot way is not what is doing today on the market for authentication format. Today it's x509 or PGP. So I do prefer to stay as standard as possible, this does not mean we can not support the FTD stuff. But IMHO it's not the right way. x509 only defines the certificate format, not how it is used to sign kernel, initramfs and device tree. The kernel defines its own format based on ELF and store the signature inside. That can't be reused directly for the kernel itself, initramfs or DTB. UEFI has again its own format. We don't want to sign kernel, initramfs and DTB individually, as this would allow an attacker to mix-and-match these to trigger a vulnerability. So we need to have some format which supports signing a given configuration consisting of specific kernel, initramfs and DTB. FIT handles this requirement. It also supports having multiple configurations (each signed) referencing for example the same kernel +initramfs but different DTBs for a set of similar boards. What is the image format you intend to use with x509 certs? I'm not talking about FIT format but the key FTD format I do not like and do not want to use the FTD format to store the key but x509. Image format need to be 100% seperated from key format. That's why I work on a framework so we do not care of both. Multiple image format with multiple image of key format. So internally we will store the key in our own format so we can do what we want. Best Regards, J. ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [RFC 2/4] Add rsa support
On Mo, 2015-03-16 at 12:33 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: I do not like and do not want to use the FTD format to store the key but x509. Yes, I think we are in agreement that we need to support both key formats. Image format need to be 100% seperated from key format. Of course. That's why I work on a framework so we do not care of both. Multiple image format with multiple image of key format. Could you explain your image format in a bit more detail? How your intend to defend against a mix-and-match attack? Regards, Jan -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [RFC 2/4] Add rsa support
On 11:00 Mon 16 Mar , Jan Lübbe wrote: Hi, On Fr, 2015-03-13 at 16:49 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: you just need to have a unique ID on the HW and then use a x509 object to store it. then signed it with you CA. As only validated keys can be used, you can easly give a generated key for a specific HW. And this key will be valid only for this HW. Yes, this sounds useful. So you'd have a board-specific way to check the unique ID constraint in an intermediate cert against the HW ID? yes more or less but but at the key itself as you will have to upload the key to the board. And the key will only be accepted to be stored as it will be valid and have the HW ID. And for the record remember if you want to use module in secured boot mode for the kernel you will have to use x509 certificate anyway. So why not to use the same principal. u-boot way is not what is doing today on the market for authentication format. Today it's x509 or PGP. So I do prefer to stay as standard as possible, this does not mean we can not support the FTD stuff. But IMHO it's not the right way. We may have to even support the Microsoft format. Specially if we want to be able one day (my personnal target) a real replacement for grub2 too. Best Regards, J. ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [RFC 2/4] Add rsa support
On Fr, 2015-03-13 at 11:25 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 11:10 Fri 13 Mar , Jan Lübbe wrote: On Fr, 2015-03-13 at 10:56 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: Having an ASN1 parser for DER/x509 is a huge amount of complexity I would not want in a bootloader. Just take a look at the problems the SSL-CAs and browsers had with different interpretations of the same cert. der is nothing few under lines Sorry, I can't parse this. x509 a few more as it's based on DER Could you show me that code? let me finish to clean it and rebase it Sure. The FIT format (and corresponding public key in the bootloader's DT) has been adopted by depthcharge and u-boot, because it handles the requirements and nothing more. if you want to add this format you can but via the keychain loader not in the code as today you do have soc such as imx that store the key in OTP as DER The IMX does not store keys in OTP. It stores a SHA(1 or 256) hash over a table of super root keys. This is irrelevant for barebox, as this is already handled by the ROM code. it's does as you can use it as hw IP to check the kernel RSA checking in HABv4 (i.e. MX6) is done in software by the ROM code. For the first step we should only support RSA in software to keep the complexity down. yes you store a hash but you do can use it in barebox. Yes, you could use it in barebox. What is the use case where you would do this instead of having the key compiled-in (and verified together with the code by the ROM)? other SoC (i can mention the name NDA) does store the key in the OTP of the SoC programmed at production time of the SoC itself. with HW RSA accelerator OK, please leave HW RSA as a future step. and u-boot is not the best reference EVER. Depthcharge is much more relevant here, as it's used as a coreboot payload on chromebooks. does not make it more relevant is the term of key format the Standard are x509, PGP and der/pem for ages and as said we can support it but make it the only one NO WAY I'd prefer PGP to x509 anyway. ;) If we can have x509 and FIT (with key in DT) without too much additional complexity and have each optional at compile time, I'm not against it. I'll wait for your code. What is your use-case for which you need to add keys at runtime? simple you want to allow user to put their own key or use a CA to handle allowed key if you want to replace grub this is critical We have customers which require that do not allow runtime loading of keys. So it should be possible to disable runtime loading at compile time. yeah of cource but the feature need to be here IMHO OK. and honestly to respect the opensource if you allow this you MIGHT be compliant with GPLv3 s/compliant/non-compliant/ ? How you need to handle that in practice depends on the context of the whole system. it's more user friendly For my own customer I always recommand to have a board uniq key that you can provide to each end customer upon request to it can install it's own linux. Even if the key is not replaceble. Yes, that's nice if the production work flow in the factory can do this, but it's not always possible. Regards, Jan -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [RFC 2/4] Add rsa support
On Fr, 2015-03-13 at 10:56 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: Having an ASN1 parser for DER/x509 is a huge amount of complexity I would not want in a bootloader. Just take a look at the problems the SSL-CAs and browsers had with different interpretations of the same cert. der is nothing few under lines Sorry, I can't parse this. x509 a few more as it's based on DER Could you show me that code? The FIT format (and corresponding public key in the bootloader's DT) has been adopted by depthcharge and u-boot, because it handles the requirements and nothing more. if you want to add this format you can but via the keychain loader not in the code as today you do have soc such as imx that store the key in OTP as DER The IMX does not store keys in OTP. It stores a SHA(1 or 256) hash over a table of super root keys. This is irrelevant for barebox, as this is already handled by the ROM code. and u-boot is not the best reference EVER. Depthcharge is much more relevant here, as it's used as a coreboot payload on chromebooks. What is your use-case for which you need to add keys at runtime? simple you want to allow user to put their own key or use a CA to handle allowed key if you want to replace grub this is critical We have customers which require that do not allow runtime loading of keys. So it should be possible to disable runtime loading at compile time. Regards, Jan -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [RFC 2/4] Add rsa support
On Fri, Mar 13, 2015 at 10:56:54AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 10:35 Fri 13 Mar , Jan Lübbe wrote: On Do, 2015-03-12 at 18:47 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: as state in my previous e-mail I will a keystore support but this dt format to handle no please we need to use the standard format as in the kernel or openssl DER and x509 specially x509 as if we want to be able to add key at runtime we need to sign them we the trusted RO keys For the implementation of RSA I use the polarssl one and plan to add the kernel one and this implementation is limited to 4096 the polarssl one is not Having an ASN1 parser for DER/x509 is a huge amount of complexity I would not want in a bootloader. Just take a look at the problems the SSL-CAs and browsers had with different interpretations of the same cert. der is nothing few under lines Could you please write something that even remotely makes sense so we can translate it here? Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [RFC 2/4] Add rsa support
On 11:22 Fri 13 Mar , Jan Lübbe wrote: On Fr, 2015-03-13 at 11:12 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: sorry mutt via ssh lost some character when typing der is few 100s line of code that's all and x509 just a few more as I do not plan to support all the options of x509 specially the non standard one Do you intend to reject unknown/unimplemented parts of x509? Or just ignore them? ignore it Best Regards, J. -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [RFC 2/4] Add rsa support
On 11:06 Fri 13 Mar , Sascha Hauer wrote: On Fri, Mar 13, 2015 at 10:56:54AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 10:35 Fri 13 Mar , Jan Lübbe wrote: On Do, 2015-03-12 at 18:47 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: as state in my previous e-mail I will a keystore support but this dt format to handle no please we need to use the standard format as in the kernel or openssl DER and x509 specially x509 as if we want to be able to add key at runtime we need to sign them we the trusted RO keys For the implementation of RSA I use the polarssl one and plan to add the kernel one and this implementation is limited to 4096 the polarssl one is not Having an ASN1 parser for DER/x509 is a huge amount of complexity I would not want in a bootloader. Just take a look at the problems the SSL-CAs and browsers had with different interpretations of the same cert. der is nothing few under lines Could you please write something that even remotely makes sense so we can translate it here? sorry mutt via ssh lost some character when typing der is few 100s line of code that's all and x509 just a few more as I do not plan to support all the options of x509 specially the non standard one Best Regards, J. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [RFC 2/4] Add rsa support
On Fr, 2015-03-13 at 11:12 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: sorry mutt via ssh lost some character when typing der is few 100s line of code that's all and x509 just a few more as I do not plan to support all the options of x509 specially the non standard one Do you intend to reject unknown/unimplemented parts of x509? Or just ignore them? -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [RFC 2/4] Add rsa support
On Do, 2015-03-12 at 18:47 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: as state in my previous e-mail I will a keystore support but this dt format to handle no please we need to use the standard format as in the kernel or openssl DER and x509 specially x509 as if we want to be able to add key at runtime we need to sign them we the trusted RO keys For the implementation of RSA I use the polarssl one and plan to add the kernel one and this implementation is limited to 4096 the polarssl one is not Having an ASN1 parser for DER/x509 is a huge amount of complexity I would not want in a bootloader. Just take a look at the problems the SSL-CAs and browsers had with different interpretations of the same cert. The FIT format (and corresponding public key in the bootloader's DT) has been adopted by depthcharge and u-boot, because it handles the requirements and nothing more. What is your use-case for which you need to add keys at runtime? Regards, Jan -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [RFC 2/4] Add rsa support
On 10:35 Fri 13 Mar , Jan Lübbe wrote: On Do, 2015-03-12 at 18:47 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: as state in my previous e-mail I will a keystore support but this dt format to handle no please we need to use the standard format as in the kernel or openssl DER and x509 specially x509 as if we want to be able to add key at runtime we need to sign them we the trusted RO keys For the implementation of RSA I use the polarssl one and plan to add the kernel one and this implementation is limited to 4096 the polarssl one is not Having an ASN1 parser for DER/x509 is a huge amount of complexity I would not want in a bootloader. Just take a look at the problems the SSL-CAs and browsers had with different interpretations of the same cert. der is nothing few under lines x509 a few more as it's based on DER The FIT format (and corresponding public key in the bootloader's DT) has been adopted by depthcharge and u-boot, because it handles the requirements and nothing more. if you want to add this format you can but via the keychain loader not in the code as today you do have soc such as imx that store the key in OTP as DER and u-boot is not the best reference EVER. What is your use-case for which you need to add keys at runtime? simple you want to allow user to put their own key or use a CA to handle allowed key if you want to replace grub this is critical Best Regards, J. Regards, Jan -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [RFC 2/4] Add rsa support
On 11:10 Fri 13 Mar , Jan Lübbe wrote: On Fr, 2015-03-13 at 10:56 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: Having an ASN1 parser for DER/x509 is a huge amount of complexity I would not want in a bootloader. Just take a look at the problems the SSL-CAs and browsers had with different interpretations of the same cert. der is nothing few under lines Sorry, I can't parse this. x509 a few more as it's based on DER Could you show me that code? let me finish to clean it and rebase it The FIT format (and corresponding public key in the bootloader's DT) has been adopted by depthcharge and u-boot, because it handles the requirements and nothing more. if you want to add this format you can but via the keychain loader not in the code as today you do have soc such as imx that store the key in OTP as DER The IMX does not store keys in OTP. It stores a SHA(1 or 256) hash over a table of super root keys. This is irrelevant for barebox, as this is already handled by the ROM code. it's does as you can use it as hw IP to check the kernel yes you store a hash but you do can use it in barebox. other SoC (i can mention the name NDA) does store the key in the OTP of the SoC programmed at production time of the SoC itself. with HW RSA accelerator and u-boot is not the best reference EVER. Depthcharge is much more relevant here, as it's used as a coreboot payload on chromebooks. does not make it more relevant is the term of key format the Standard are x509, PGP and der/pem for ages and as said we can support it but make it the only one NO WAY What is your use-case for which you need to add keys at runtime? simple you want to allow user to put their own key or use a CA to handle allowed key if you want to replace grub this is critical We have customers which require that do not allow runtime loading of keys. So it should be possible to disable runtime loading at compile time. yeah of cource but the feature need to be here IMHO and honestly to respect the opensource if you allow this you MIGHT be compliant with GPLv3 it's more user friendly For my own customer I always recommand to have a board uniq key that you can provide to each end customer upon request to it can install it's own linux. Even if the key is not replaceble. Best Regards, J. Regards, Jan -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [RFC 2/4] Add rsa support
On 11:43 Fri 13 Mar , Jan Lübbe wrote: On Fr, 2015-03-13 at 11:25 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 11:10 Fri 13 Mar , Jan Lübbe wrote: On Fr, 2015-03-13 at 10:56 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: Having an ASN1 parser for DER/x509 is a huge amount of complexity I would not want in a bootloader. Just take a look at the problems the SSL-CAs and browsers had with different interpretations of the same cert. der is nothing few under lines Sorry, I can't parse this. x509 a few more as it's based on DER Could you show me that code? let me finish to clean it and rebase it Sure. The FIT format (and corresponding public key in the bootloader's DT) has been adopted by depthcharge and u-boot, because it handles the requirements and nothing more. if you want to add this format you can but via the keychain loader not in the code as today you do have soc such as imx that store the key in OTP as DER The IMX does not store keys in OTP. It stores a SHA(1 or 256) hash over a table of super root keys. This is irrelevant for barebox, as this is already handled by the ROM code. it's does as you can use it as hw IP to check the kernel RSA checking in HABv4 (i.e. MX6) is done in software by the ROM code. For the first step we should only support RSA in software to keep the complexity down. yes you store a hash but you do can use it in barebox. Yes, you could use it in barebox. What is the use case where you would do this instead of having the key compiled-in (and verified together with the code by the ROM)? yes let the rom code handle it if you want, it will be a HW implementation specific to IMX with HABv4 The framework must not be limited to FIT only but FIT is just one of secure boot supported other SoC (i can mention the name NDA) does store the key in the OTP of the SoC programmed at production time of the SoC itself. with HW RSA accelerator OK, please leave HW RSA as a future step. The current framework is already ready for this mostly and u-boot is not the best reference EVER. Depthcharge is much more relevant here, as it's used as a coreboot payload on chromebooks. does not make it more relevant is the term of key format the Standard are x509, PGP and der/pem for ages and as said we can support it but make it the only one NO WAY I'd prefer PGP to x509 anyway. ;) I do prefer PGP too but unfortunately it's not a flexibal format If we can have x509 and FIT (with key in DT) without too much additional complexity and have each optional at compile time, I'm not against it. I'll wait for your code. What is your use-case for which you need to add keys at runtime? simple you want to allow user to put their own key or use a CA to handle allowed key if you want to replace grub this is critical We have customers which require that do not allow runtime loading of keys. So it should be possible to disable runtime loading at compile time. yeah of cource but the feature need to be here IMHO OK. and honestly to respect the opensource if you allow this you MIGHT be compliant with GPLv3 s/compliant/non-compliant/ ? compliant we had layer checking it for one of my client in the pase, I'll ask for the result How you need to handle that in practice depends on the context of the whole system. it's more user friendly For my own customer I always recommand to have a board uniq key that you can provide to each end customer upon request to it can install it's own linux. Even if the key is not replaceble. Yes, that's nice if the production work flow in the factory can do this, but it's not always possible. if you use x509 you can you just need to have a unique ID on the HW and then use a x509 object to store it. then signed it with you CA. As only validated keys can be used, you can easly give a generated key for a specific HW. And this key will be valid only for this HW. Already did it in the past on u-boot and barebox Best Regards, J. ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
[RFC 2/4] Add rsa support
From: Sascha Hauer s.ha...@pengutronix.de
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
crypto/Kconfig | 3 +
crypto/Makefile | 1 +
crypto/rsa.c| 411
include/asm-generic/errno.h | 5 +
include/rsa.h | 54 ++
5 files changed, 474 insertions(+)
create mode 100644 crypto/rsa.c
create mode 100644 include/rsa.h
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 4bd8dcf359f8..fa9ba491b79b 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -25,3 +25,6 @@ config SHA256
bool SHA256
endif
+
+config RSA
+ bool
diff --git a/crypto/Makefile b/crypto/Makefile
index 7c5b035b73de..44be124aa368 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_MD5) += md5.o
obj-$(CONFIG_SHA1) += sha1.o
obj-$(CONFIG_SHA224) += sha2.o
obj-$(CONFIG_SHA256) += sha2.o
+obj-$(CONFIG_RSA) += rsa.o
diff --git a/crypto/rsa.c b/crypto/rsa.c
new file mode 100644
index ..6a0c7b8a15cc
--- /dev/null
+++ b/crypto/rsa.c
@@ -0,0 +1,411 @@
+/*
+ * Copyright (c) 2013, Google Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include malloc.h
+#include of.h
+#include digest.h
+#include asm/types.h
+#include asm/byteorder.h
+#include errno.h
+#include rsa.h
+#include asm/types.h
+#include asm/unaligned.h
+
+#define UINT64_MULT32(v, multby) (((uint64_t)(v)) * ((uint32_t)(multby)))
+
+#define get_unaligned_be32(a) fdt32_to_cpu(*(uint32_t *)a)
+#define put_unaligned_be32(a, b) (*(uint32_t *)(b) = cpu_to_fdt32(a))
+
+/* Default public exponent for backward compatibility */
+#define RSA_DEFAULT_PUBEXP 65537
+
+/* This is the minimum/maximum key size we support, in bits */
+#define RSA_MIN_KEY_BITS 1024
+#define RSA_MAX_KEY_BITS 4096
+
+/**
+ * subtract_modulus() - subtract modulus from the given value
+ *
+ * @key: Key containing modulus to subtract
+ * @num: Number to subtract modulus from, as little endian word array
+ */
+static void subtract_modulus(const struct rsa_public_key *key, uint32_t num[])
+{
+ int64_t acc = 0;
+ uint i;
+
+ for (i = 0; i key-len; i++) {
+ acc += (uint64_t)num[i] - key-modulus[i];
+ num[i] = (uint32_t)acc;
+ acc = 32;
+ }
+}
+
+/**
+ * greater_equal_modulus() - check if a value is = modulus
+ *
+ * @key: Key containing modulus to check
+ * @num: Number to check against modulus, as little endian word array
+ * @return 0 if num modulus, 1 if num = modulus
+ */
+static int greater_equal_modulus(const struct rsa_public_key *key,
+uint32_t num[])
+{
+ int i;
+
+ for (i = (int)key-len - 1; i = 0; i--) {
+ if (num[i] key-modulus[i])
+ return 0;
+ if (num[i] key-modulus[i])
+ return 1;
+ }
+
+ return 1; /* equal */
+}
+
+/**
+ * montgomery_mul_add_step() - Perform montgomery multiply-add step
+ *
+ * Operation: montgomery result[] += a * b[] / n0inv % modulus
+ *
+ * @key: RSA key
+ * @result:Place to put result, as little endian word array
+ * @a: Multiplier
+ * @b: Multiplicand, as little endian word array
+ */
+static void montgomery_mul_add_step(const struct rsa_public_key *key,
+ uint32_t result[], const uint32_t a, const uint32_t b[])
+{
+ uint64_t acc_a, acc_b;
+ uint32_t d0;
+ uint i;
+
+ acc_a = (uint64_t)a * b[0] + result[0];
+ d0 = (uint32_t)acc_a * key-n0inv;
+ acc_b = (uint64_t)d0 * key-modulus[0] + (uint32_t)acc_a;
+ for (i = 1; i key-len; i++) {
+ acc_a = (acc_a 32) + (uint64_t)a * b[i] + result[i];
+ acc_b = (acc_b 32) + (uint64_t)d0 * key-modulus[i] +
+ (uint32_t)acc_a;
+ result[i - 1] = (uint32_t)acc_b;
+ }
+
+ acc_a = (acc_a 32) + (acc_b 32);
+
+ result[i - 1] = (uint32_t)acc_a;
+
+ if (acc_a 32)
+ subtract_modulus(key, result);
+}
+
+/**
+ * montgomery_mul() - Perform montgomery mutitply
+ *
+ * Operation: montgomery result[] = a[] * b[] / n0inv % modulus
+ *
+ * @key: RSA key
+ * @result:Place to put result, as little endian word array
+ * @a: Multiplier, as little endian word array
+ * @b: Multiplicand, as little endian word array
+ */
+static void montgomery_mul(const struct rsa_public_key *key,
+ uint32_t result[], uint32_t a[], const uint32_t b[])
+{
+ uint i;
+
+ for (i = 0; i key-len; ++i)
+ result[i] = 0;
+ for (i = 0; i key-len; ++i)
+ montgomery_mul_add_step(key, result, a[i], b);
+}
+
+/**
+ * num_pub_exponent_bits() - Number of bits in the public exponent
+ *
+ * @key: RSA key
+ * @num_bits: Storage for the number of public exponent bits
+ */
+static int
Re: [RFC 2/4] Add rsa support
On 15:39 Thu 12 Mar , Jan Luebbe wrote:
From: Sascha Hauer s.ha...@pengutronix.de
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
crypto/Kconfig | 3 +
crypto/Makefile | 1 +
crypto/rsa.c| 411
include/asm-generic/errno.h | 5 +
include/rsa.h | 54 ++
5 files changed, 474 insertions(+)
create mode 100644 crypto/rsa.c
create mode 100644 include/rsa.h
as state in my previous e-mail I will a keystore support
but this dt format to handle no please
we need to use the standard format as in the kernel or openssl
DER and x509
specially x509 as if we want to be able to add key at runtime we need to sign
them we the trusted RO keys
For the implementation of RSA I use the polarssl one and plan to add
the kernel one
and this implementation is limited to 4096 the polarssl one is not
Best Regards,
J.
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 4bd8dcf359f8..fa9ba491b79b 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -25,3 +25,6 @@ config SHA256
bool SHA256
endif
+
+config RSA
+ bool
diff --git a/crypto/Makefile b/crypto/Makefile
index 7c5b035b73de..44be124aa368 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_MD5) += md5.o
obj-$(CONFIG_SHA1) += sha1.o
obj-$(CONFIG_SHA224) += sha2.o
obj-$(CONFIG_SHA256) += sha2.o
+obj-$(CONFIG_RSA)+= rsa.o
diff --git a/crypto/rsa.c b/crypto/rsa.c
new file mode 100644
index ..6a0c7b8a15cc
--- /dev/null
+++ b/crypto/rsa.c
@@ -0,0 +1,411 @@
+/*
+ * Copyright (c) 2013, Google Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include common.h
+#include malloc.h
+#include of.h
+#include digest.h
+#include asm/types.h
+#include asm/byteorder.h
+#include errno.h
+#include rsa.h
+#include asm/types.h
+#include asm/unaligned.h
+
+#define UINT64_MULT32(v, multby) (((uint64_t)(v)) * ((uint32_t)(multby)))
+
+#define get_unaligned_be32(a) fdt32_to_cpu(*(uint32_t *)a)
+#define put_unaligned_be32(a, b) (*(uint32_t *)(b) = cpu_to_fdt32(a))
+
+/* Default public exponent for backward compatibility */
+#define RSA_DEFAULT_PUBEXP 65537
+
+/* This is the minimum/maximum key size we support, in bits */
+#define RSA_MIN_KEY_BITS 1024
+#define RSA_MAX_KEY_BITS 4096
+
+/**
+ * subtract_modulus() - subtract modulus from the given value
+ *
+ * @key: Key containing modulus to subtract
+ * @num: Number to subtract modulus from, as little endian word array
+ */
+static void subtract_modulus(const struct rsa_public_key *key, uint32_t
num[])
+{
+ int64_t acc = 0;
+ uint i;
+
+ for (i = 0; i key-len; i++) {
+ acc += (uint64_t)num[i] - key-modulus[i];
+ num[i] = (uint32_t)acc;
+ acc = 32;
+ }
+}
+
+/**
+ * greater_equal_modulus() - check if a value is = modulus
+ *
+ * @key: Key containing modulus to check
+ * @num: Number to check against modulus, as little endian word array
+ * @return 0 if num modulus, 1 if num = modulus
+ */
+static int greater_equal_modulus(const struct rsa_public_key *key,
+ uint32_t num[])
+{
+ int i;
+
+ for (i = (int)key-len - 1; i = 0; i--) {
+ if (num[i] key-modulus[i])
+ return 0;
+ if (num[i] key-modulus[i])
+ return 1;
+ }
+
+ return 1; /* equal */
+}
+
+/**
+ * montgomery_mul_add_step() - Perform montgomery multiply-add step
+ *
+ * Operation: montgomery result[] += a * b[] / n0inv % modulus
+ *
+ * @key: RSA key
+ * @result: Place to put result, as little endian word array
+ * @a: Multiplier
+ * @b: Multiplicand, as little endian word array
+ */
+static void montgomery_mul_add_step(const struct rsa_public_key *key,
+ uint32_t result[], const uint32_t a, const uint32_t b[])
+{
+ uint64_t acc_a, acc_b;
+ uint32_t d0;
+ uint i;
+
+ acc_a = (uint64_t)a * b[0] + result[0];
+ d0 = (uint32_t)acc_a * key-n0inv;
+ acc_b = (uint64_t)d0 * key-modulus[0] + (uint32_t)acc_a;
+ for (i = 1; i key-len; i++) {
+ acc_a = (acc_a 32) + (uint64_t)a * b[i] + result[i];
+ acc_b = (acc_b 32) + (uint64_t)d0 * key-modulus[i] +
+ (uint32_t)acc_a;
+ result[i - 1] = (uint32_t)acc_b;
+ }
+
+ acc_a = (acc_a 32) + (acc_b 32);
+
+ result[i - 1] = (uint32_t)acc_a;
+
+ if (acc_a 32)
+ subtract_modulus(key, result);
+}
+
+/**
+ * montgomery_mul() - Perform montgomery mutitply
+ *
+ * Operation: montgomery result[] = a[] * b[] / n0inv % modulus
+ *
+ * @key: RSA key
+ * @result: Place to put result, as little endian word array
+ * @a: Multiplier, as little endian word array
+
