Re: [RFC 3/4] FIT: add FIT image support
On 14:28 Mon 16 Mar , Jan Lübbe wrote: On Mo, 2015-03-16 at 13:19 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 13:08 Mon 16 Mar , Jan Lübbe wrote: On Mo, 2015-03-16 at 12:14 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 11:19 Mon 16 Mar , Jan Lübbe wrote: Later I'd like to have optional support to switch barebox into a non-secure or developer mode at runtime, which would make hardware secrets inaccessible. That could be triggered when a prompt appears or when booting for a different source (such as USB fastboot). yeah, I like the idea but for this will have to put a lot of protection so you can not read/write some part of the memory included barebox itself (in RAM) As in the kernel we have no memmory protection from the shell. Not necessarily. For example on the MX6 you can trigger a security violation in the CAAM from software. That will clear the OTPMK in its Key-RAM. From that point on you can run any software but you will not be able to decrypt any secret data which was encrypted with the OTPMK. On hardware which supports something like this, debugging hardware problems is easy and there is no danger of leaking any secret information. If something is useful/possible in any specific project obviously depends on the threat model and hardware capabilities. I knonw about the imx6 but that does not mean all the SoC unfortunatly. Yes, every SoC is different. But we should be able to use HW features when the are available, as sometimes the HW is selected specifically to used these security features. I agree with you we just need to ensure that it work also when we can not use such HW feature. The other pb I see is this one where and do you plan to store the RO x509 the trusted one. Sorry, I can't parse this. where do we store the trusted keys/cert need to be secured or inaccessible except crypto API if you use on OTP this means this is enough to ensure secured boot as if you can not modify the primary cert of key. No one can brake it. But as you load it in ram you need to be sure no one modify it. Even in unlock mode to do only allow to boot secure images by expected key. I should have been more clear: The use case here is to ensure that the OTPMK-AES-HW-Key is only available when booting with a correct boot chain. It's OK to boot something else (only the OTPMK needs to be cleared). This is a very different goal from making sure that only correctly signed code is executed. Both cases need mostly the same verified boot features, only the policy (especially what to do on signature errors) is different. secure boot means in 95% of the case only correctly signed file can be booted So you may not have secured place to store the cert or key in ram but only RAM. so we do need to forbidden this memory acces to everyone except the crypto API. if we want ot allow dev mode. On MX6 this can be done by the HW. Doing this (without TrustZone) purely in SW seems extremely difficult. if you do not allow console easy, if you do you need to make the memory where you do store the trusted keys and barebox itself no accessible by any std API or command such as md/mw, etc... yes this will be difficult Best Regards, J. ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 07/10] password: add pbkdf2 support
On 14:14 Mon 16 Mar , Jan Lübbe wrote: On Mo, 2015-03-16 at 13:10 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 12:58 Mon 16 Mar , Jan Lübbe wrote: Personnaly I'll prefer a random 64 bytes | sha256 | take first 32bytes. | pbkdf2 1 round Running SHA-256 on random data is useless for security. SHA256 is to improve the entrpopy not security Running a deterministic algorithm cannot increase entropy (only reduce it). check the kennel algo for PRGN PRNG? That is a different use case. The kernel takes sources of entropy and uses those to seed an CSPRNG: http://www.2uo.de/myths-about-urandom/ I known how work urandom and random but the kernel do use SHA-1 for generating the Random numbers. I do not want to go to deep in the algo we can look at the code. and youp will see why I want to use a sha Having high entropy and appearing random are different properties. As SHA-256 is deterministic it *cannot* increase entropy: http://en.wikipedia.org/wiki/Entropy_(information_theory) I known about it Just get hash-size bytes from /dev/urandom on the host. We could generate a file with the compile-time SALT which is then included. On the running barebox, we could use SHA to hash the old password file together with the current timer value. At least until we have something better. result a 64 bytes password file salt 32 byeskey 32 bytes Yes. As we select the algorithm at compile time, we don't the to save it in the file. this is for barebox as we may not have any passwd file The same applies also to the default_passwd compiled in variable. Currently we have: PASSWD_FILE := $(shell cd $(srctree); find $(CONFIG_PASSWORD_DEFAULT) -type f) cmd_pwd_h = echo -n static const char default_passwd[] = \ $@; \ cat $ | tr -d '\n' $@; \ echo \; $@ include/generated/passwd.h: $(PASSWD_FILE) $(call if_changed,pwd_h) This would need to run the hash/pbkdf2 and store salt+key. no as the current current code expect you to give the correct file format for the currently use password so today the output of openssl Ah, sorry I misread the code here. I though that the plaintext password was in the config. CONFIG_PASSWORD_DEFAULT must be the name of a file in the srctree with the format matching the selected hash algo? but yes we may need to do more here It seems there is no standard tool to create password hashes which supports all the algorithms we want to have. So the current way is to use barebox itself to create the default password file? Should be have a host tool for that or is barebox sandbox enough? yes sandbox is enough we can create such tool but today it's just the sha of the password store in base64 so you can easly create it in shell if we start to play we random salt yes we do need a tool Best Regards, J. ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [RFC 3/4] FIT: add FIT image support
On Mo, 2015-03-16 at 14:51 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: The other pb I see is this one where and do you plan to store the RO x509 the trusted one. Sorry, I can't parse this. where do we store the trusted keys/cert need to be secured or inaccessible except crypto API (The following depends on prohibiting any unauthenticated access to the barebox console.) If you just use a chain of signed code like with HAB on i.MX, every cert is verified by the previous step (up to the SRK table hash), so there is no need to additionally protect certs against modification. Any modified cert would result in a verification error. In this setup there is no secret information on the device at all. When doing this without support from the SoC's ROM code, you could store barebox (with compiled-in master public key(s)) in RO flash. Against an attacker without physical access, this results in the same security properties. You couldn't update the RO barebox, tough (only boot another one second stage). 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 3/4] FIT: add FIT image support
On Mo, 2015-03-16 at 13:19 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 13:08 Mon 16 Mar , Jan Lübbe wrote: On Mo, 2015-03-16 at 12:14 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 11:19 Mon 16 Mar , Jan Lübbe wrote: Later I'd like to have optional support to switch barebox into a non-secure or developer mode at runtime, which would make hardware secrets inaccessible. That could be triggered when a prompt appears or when booting for a different source (such as USB fastboot). yeah, I like the idea but for this will have to put a lot of protection so you can not read/write some part of the memory included barebox itself (in RAM) As in the kernel we have no memmory protection from the shell. Not necessarily. For example on the MX6 you can trigger a security violation in the CAAM from software. That will clear the OTPMK in its Key-RAM. From that point on you can run any software but you will not be able to decrypt any secret data which was encrypted with the OTPMK. On hardware which supports something like this, debugging hardware problems is easy and there is no danger of leaking any secret information. If something is useful/possible in any specific project obviously depends on the threat model and hardware capabilities. I knonw about the imx6 but that does not mean all the SoC unfortunatly. Yes, every SoC is different. But we should be able to use HW features when the are available, as sometimes the HW is selected specifically to used these security features. The other pb I see is this one where and do you plan to store the RO x509 the trusted one. Sorry, I can't parse this. if you use on OTP this means this is enough to ensure secured boot as if you can not modify the primary cert of key. No one can brake it. But as you load it in ram you need to be sure no one modify it. Even in unlock mode to do only allow to boot secure images by expected key. I should have been more clear: The use case here is to ensure that the OTPMK-AES-HW-Key is only available when booting with a correct boot chain. It's OK to boot something else (only the OTPMK needs to be cleared). This is a very different goal from making sure that only correctly signed code is executed. Both cases need mostly the same verified boot features, only the policy (especially what to do on signature errors) is different. So you may not have secured place to store the cert or key in ram but only RAM. so we do need to forbidden this memory acces to everyone except the crypto API. if we want ot allow dev mode. On MX6 this can be done by the HW. Doing this (without TrustZone) purely in SW seems extremely difficult. the main problem is not console but env you need to drop RW env support and use only RO one, except for keyring support where you will a RW env but not executable and only accesable by crypto API otherwise you need to use a secured digest such as HMAC/CMAC/OMAC support to sign the env at runtime and ensure the symetric key is secured or encrypt it via aes (did this in the past) For an upcoming project we'll add HMAC support to the state storage Marc recently submitted. I've a patch too I need to send it For environment or state storage? envfs Nice. :) but I prefer to wait we have keystore support as this will store the key for the HMAC otherwise we need to use HW HMAC that store the key in the soc Another possibility is to use the HW AES key and a compiled in value to derive a per-device HMAC secret. The same approach can also be used in Linux for deriving the IMA/EVM HMAC secret. this for me need to be integrated in the keystore to be transparent for the rest of the API That shouldn't be hard. We can look at this in detail after you've posted that API. 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 3/4] FIT: add FIT image support
On 11:19 Mon 16 Mar , Jan Lübbe wrote: Hi Jean-Christophe, On Fr, 2015-03-13 at 17:08 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 16:41 Fri 13 Mar , Jan Lübbe wrote: On Fr, 2015-03-13 at 15:28 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: It's not the job of barebox to define security policies, it must fit well into the larger security design, which may require compromises. I disagree, disable by default non secure feature is require to pass secure boot certification Is there a specific certification you are targeting? yes but can not give details all under NDA, a book of more than 500 pages for bootloader/linux/kernel co OK, that's unfortunate. Still I'd like to have some documentation on the overall design of Barebox's verified boot. That doesn't mean you have to write it all by yourself. ;) I'll already pass the certification but it's a nightmare. I wish to have a mainline version that can pass it How do you intend to handle console access in verified boot mode? Allowing access to md/mw would break any security. it's already mainline for month, check password support as I put it in production more than 1 years ago or simple disable input console all time, the code is here So currently we have: 1) use password 2) disable console console enable but require a password to unlock I've on an other hw HMAC for envfs to ensure envfs is not tempenred with. I've on an other HW where we encrypt in in AES CBC or AES-XTS (this one not yet in production in qualification) Later I'd like to have optional support to switch barebox into a non-secure or developer mode at runtime, which would make hardware secrets inaccessible. That could be triggered when a prompt appears or when booting for a different source (such as USB fastboot). yeah, I like the idea but for this will have to put a lot of protection so you can not read/write some part of the memory included barebox itself (in RAM) As in the kernel we have no memmory protection from the shell. the main problem is not console but env you need to drop RW env support and use only RO one, except for keyring support where you will a RW env but not executable and only accesable by crypto API otherwise you need to use a secured digest such as HMAC/CMAC/OMAC support to sign the env at runtime and ensure the symetric key is secured or encrypt it via aes (did this in the past) For an upcoming project we'll add HMAC support to the state storage Marc recently submitted. I've a patch too I need to send it but I prefer to wait we have keystore support as this will store the key for the HMAC otherwise we need to use HW HMAC that store the key in the soc ww may have to get secured malloac with part where the md/mw and any other API can not touch only the crypto API but this will be for later Yes. I'll send a patch to use the pbkdf2 for password Nice. 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: [PATCH 07/10] password: add pbkdf2 support
On Mo, 2015-03-16 at 13:10 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 12:58 Mon 16 Mar , Jan Lübbe wrote: Personnaly I'll prefer a random 64 bytes | sha256 | take first 32bytes. | pbkdf2 1 round Running SHA-256 on random data is useless for security. SHA256 is to improve the entrpopy not security Running a deterministic algorithm cannot increase entropy (only reduce it). check the kennel algo for PRGN PRNG? That is a different use case. The kernel takes sources of entropy and uses those to seed an CSPRNG: http://www.2uo.de/myths-about-urandom/ and youp will see why I want to use a sha Having high entropy and appearing random are different properties. As SHA-256 is deterministic it *cannot* increase entropy: http://en.wikipedia.org/wiki/Entropy_(information_theory) Just get hash-size bytes from /dev/urandom on the host. We could generate a file with the compile-time SALT which is then included. On the running barebox, we could use SHA to hash the old password file together with the current timer value. At least until we have something better. result a 64 bytes password file salt 32 byeskey 32 bytes Yes. As we select the algorithm at compile time, we don't the to save it in the file. this is for barebox as we may not have any passwd file The same applies also to the default_passwd compiled in variable. Currently we have: PASSWD_FILE := $(shell cd $(srctree); find $(CONFIG_PASSWORD_DEFAULT) -type f) cmd_pwd_h = echo -n static const char default_passwd[] = \ $@; \ cat $ | tr -d '\n' $@; \ echo \; $@ include/generated/passwd.h: $(PASSWD_FILE) $(call if_changed,pwd_h) This would need to run the hash/pbkdf2 and store salt+key. no as the current current code expect you to give the correct file format for the currently use password so today the output of openssl Ah, sorry I misread the code here. I though that the plaintext password was in the config. CONFIG_PASSWORD_DEFAULT must be the name of a file in the srctree with the format matching the selected hash algo? but yes we may need to do more here It seems there is no standard tool to create password hashes which supports all the algorithms we want to have. So the current way is to use barebox itself to create the default password file? Should be have a host tool for that or is barebox sandbox enough? 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: [PATCH 8/8] command: add hmac sum supportfor md5, sha1, sha224, sha256, sha384, sha512
On Mon, Mar 16, 2015 at 12:01:32PM +0100, Jan Lübbe wrote: On Mi, 2015-03-11 at 17:53 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: diff --git a/include/digest.h b/include/digest.h index a26848c..fd47a7e 100644 --- a/include/digest.h +++ b/include/digest.h @@ -54,11 +54,14 @@ struct digest *digest_alloc(char* name); void digest_free(struct digest *d); int digest_file_window(struct digest *d, char *filename, + unsigned char *key, size_t keylen, unsigned char *hash, ulong start, ulong size); int digest_file(struct digest *d, char *filename, + unsigned char *key, size_t keylen, unsigned char *hash); This is already in next, but I'd like to know why you added the key/keylen args to each function instead of letting the caller use digest_set_key()? In the patch [PATCH 04/10] command: add generic digest command you add another parameter (unsigned char *sig) to these functions, which is used instead of the key parameter when verifying. Maybe we are overloading them with to much different functionality? I agree here. For the caller of digest_file() it is equally simple to call digest_set_key() beforehand. 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
[PATCH 07/10] password: add pbkdf2 support
We will use barebox_password as salt and 1 round to generate a
64 bytes key.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
common/Kconfig| 4 +++
common/password.c | 79 +++
2 files changed, 55 insertions(+), 28 deletions(-)
diff --git a/common/Kconfig b/common/Kconfig
index 96ace6b..ad8a596 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -453,6 +453,10 @@ config PASSWD_SUM_SHA512
bool SHA512
select SHA512
+config PASSWD_CRYPTO_PBKDF2
+ bool PBKDF2
+ select CRYPTO_PBKDF2
+
endchoice
endif
diff --git a/common/password.c b/common/password.c
index 6ecf717..0e1db61 100644
--- a/common/password.c
+++ b/common/password.c
@@ -26,6 +26,7 @@
#include xfuncs.h
#include clock.h
#include generated/passwd.h
+#include crypto/pbkdf2.h
#if defined(CONFIG_PASSWD_SUM_MD5)
#define PASSWD_SUM md5
@@ -35,8 +36,14 @@
#define PASSWD_SUM sha256
#elif defined(CONFIG_PASSWD_SUM_SHA512)
#define PASSWD_SUM sha512
+#else
+#define PASSWD_SUM NULL
#endif
+#define PBKDF2_SALTbarebox_password
+#define PBKDF2_LENGTH 64
+#define PBKDF2_COUNT 1
+
int password(unsigned char *passwd, size_t length, int flags, int timeout)
{
unsigned char *buf = passwd;
@@ -277,45 +284,50 @@ EXPORT_SYMBOL(write_env_passwd);
static int __check_passwd(unsigned char* passwd, size_t length, int std)
{
- struct digest *d;
+ struct digest *d = NULL;
unsigned char *passwd1_sum;
unsigned char *passwd2_sum;
int ret = 0;
+ int hash_len;
- d = digest_alloc(PASSWD_SUM);
+ if (IS_ENABLED(CONFIG_PASSWD_CRYPTO_PBKDF2)) {
+ hash_len = PBKDF2_LENGTH;
+ } else {
+ d = digest_alloc(PASSWD_SUM);
- passwd1_sum = calloc(digest_length(d), sizeof(unsigned char));
+ hash_len = digest_length(d);
+ }
+ passwd1_sum = calloc(hash_len * 2, sizeof(unsigned char));
if (!passwd1_sum)
return -ENOMEM;
- passwd2_sum = calloc(digest_length(d), sizeof(unsigned char));
-
- if (!passwd2_sum) {
- ret = -ENOMEM;
- goto err1;
- }
+ passwd2_sum = passwd1_sum + hash_len;
- digest_init(d);
+ if (IS_ENABLED(CONFIG_PASSWD_CRYPTO_PBKDF2)) {
+ char *salt = PBKDF2_SALT;
- digest_update(d, passwd, length);
+ ret = pkcs5_pbkdf2_hmac_sha1(passwd, length, salt, strlen(salt),
+ PBKDF2_COUNT, hash_len, passwd1_sum);
+ } else {
+ ret = digest_digest(d, passwd, length, passwd1_sum);
+ }
- digest_final(d, passwd1_sum);
+ if (ret)
+ goto err;
if (std)
- ret = read_env_passwd(passwd2_sum, digest_length(d));
+ ret = read_env_passwd(passwd2_sum, hash_len);
else
- ret = read_default_passwd(passwd2_sum, digest_length(d));
+ ret = read_default_passwd(passwd2_sum, hash_len);
if (ret 0)
- goto err2;
+ goto err;
- if (strncmp(passwd1_sum, passwd2_sum, digest_length(d)) == 0)
+ if (strncmp(passwd1_sum, passwd2_sum, hash_len) == 0)
ret = 1;
-err2:
- free(passwd2_sum);
-err1:
+err:
free(passwd1_sum);
digest_free(d);
@@ -346,25 +358,36 @@ int check_passwd(unsigned char* passwd, size_t length)
int set_env_passwd(unsigned char* passwd, size_t length)
{
- struct digest *d;
+ struct digest *d = NULL;
unsigned char *passwd_sum;
- int ret;
+ int ret, hash_len;
- d = digest_alloc(PASSWD_SUM);
+ if (IS_ENABLED(CONFIG_PASSWD_CRYPTO_PBKDF2)) {
+ hash_len = PBKDF2_LENGTH;
+ } else {
+ d = digest_alloc(PASSWD_SUM);
- passwd_sum = calloc(digest_length(d), sizeof(unsigned char));
+ hash_len = digest_length(d);
+ }
+ passwd_sum = calloc(hash_len, sizeof(unsigned char));
if (!passwd_sum)
return -ENOMEM;
- digest_init(d);
+ if (IS_ENABLED(CONFIG_PASSWD_CRYPTO_PBKDF2)) {
+ char *salt = PBKDF2_SALT;
- digest_update(d, passwd, length);
-
- digest_final(d, passwd_sum);
+ ret = pkcs5_pbkdf2_hmac_sha1(passwd, length, salt, strlen(salt),
+ PBKDF2_COUNT, hash_len, passwd_sum);
+ } else {
+ ret = digest_digest(d, passwd, length, passwd_sum);
+ }
+ if (ret)
+ goto err;
- ret = write_env_passwd(passwd_sum, digest_length(d));
+ ret = write_env_passwd(passwd_sum, hash_len);
+err:
free(passwd_sum);
return ret;
--
2.1.4
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 07/10] password: add pbkdf2 support
On 12:41 Mon 16 Mar , Jan Lübbe wrote: On Mo, 2015-03-16 at 12:25 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: Yes, definitely. We must use the algorithms as they are intended to be used. If we try to move users away from RSA2048 because it will be vulnerable in the future, we should not go against established practice for password salts by hard-coding it. I'm not against it but with the barebox entropy did not see the point to use it. so how do we generate the salt? what length Personnaly I'll prefer a random 64 bytes | sha256 | take first 32bytes. | pbkdf2 1 round Running SHA-256 on random data is useless for security. SHA256 is to improve the entrpopy not security Just get hash-size bytes from /dev/urandom on the host. We could generate a file with the compile-time SALT which is then included. On the running barebox, we could use SHA to hash the old password file together with the current timer value. At least until we have something better. result a 64 bytes password file salt 32 byeskey 32 bytes Yes. As we select the algorithm at compile time, we don't the to save it in the file. this is for barebox as we may not have any passwd file 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 3/4] FIT: add FIT image support
On Fr, 2015-03-13 at 18:00 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: While sha1 is considered broken. it's broken and sha256 not yet but in 10 years strongly suspected even in brut force That's why FIPS work on SHA-2 SHA256 is part of the SHA-2 family [1]. Keccak is the winner of the SHA-3 competition. Regards, Jan [1] http://en.wikipedia.org/wiki/SHA-2 -- 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: [PATCH 07/10] password: add pbkdf2 support
On Mo, 2015-03-16 at 12:01 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 11:49 Mon 16 Mar , Jan Lübbe wrote: On Mo, 2015-03-16 at 11:15 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: We will use barebox_password as salt and 1 round to generate a 64 bytes key. The purpose of a salt is to protect a against dictionary or rainbow-table (precomputed) attacks. That means that the Salt must be randomly generated and saved with the password. This will be a enough stong enven with static one to protect against reverse hack for barebox protection Use a 32 byte pass try to do an attack agaist dictionary. it will take you more than 10 years to break it For setting a new password in barebox, even a low entropy salt will make attacks significantly more expensive. So we should add some entropy from user interaction timing in that case. yes we could do this too For hashing a password at compile time, we should get the salt from the host system. yes do we really need it? Yes, definitely. We must use the algorithms as they are intended to be used. If we try to move users away from RSA2048 because it will be vulnerable in the future, we should not go against established practice for password salts by hard-coding it. 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: [PATCH 8/8] command: add hmac sum supportfor md5, sha1, sha224, sha256, sha384, sha512
On 12:01 Mon 16 Mar , Jan Lübbe wrote: On Mi, 2015-03-11 at 17:53 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: diff --git a/include/digest.h b/include/digest.h index a26848c..fd47a7e 100644 --- a/include/digest.h +++ b/include/digest.h @@ -54,11 +54,14 @@ struct digest *digest_alloc(char* name); void digest_free(struct digest *d); int digest_file_window(struct digest *d, char *filename, + unsigned char *key, size_t keylen, unsigned char *hash, ulong start, ulong size); int digest_file(struct digest *d, char *filename, + unsigned char *key, size_t keylen, unsigned char *hash); This is already in next, but I'd like to know why you added the key/keylen args to each function instead of letting the caller use digest_set_key()? In the patch [PATCH 04/10] command: add generic digest command you add another parameter (unsigned char *sig) to these functions, which is used instead of the key parameter when verifying. Maybe we are overloading them with to much different functionality? digest_file_window/digest_file the idea was to only chose the digest and lest the function to handle the rest 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: [PATCH 07/10] password: add pbkdf2 support
On Mo, 2015-03-16 at 12:52 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 12:41 Mon 16 Mar , Jan Lübbe wrote: On Mo, 2015-03-16 at 12:25 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: Yes, definitely. We must use the algorithms as they are intended to be used. If we try to move users away from RSA2048 because it will be vulnerable in the future, we should not go against established practice for password salts by hard-coding it. I'm not against it but with the barebox entropy did not see the point to use it. so how do we generate the salt? what length Personnaly I'll prefer a random 64 bytes | sha256 | take first 32bytes. | pbkdf2 1 round Running SHA-256 on random data is useless for security. SHA256 is to improve the entrpopy not security Running a deterministic algorithm cannot increase entropy (only reduce it). Just get hash-size bytes from /dev/urandom on the host. We could generate a file with the compile-time SALT which is then included. On the running barebox, we could use SHA to hash the old password file together with the current timer value. At least until we have something better. result a 64 bytes password file salt 32 byeskey 32 bytes Yes. As we select the algorithm at compile time, we don't the to save it in the file. this is for barebox as we may not have any passwd file The same applies also to the default_passwd compiled in variable. Currently we have: PASSWD_FILE := $(shell cd $(srctree); find $(CONFIG_PASSWORD_DEFAULT) -type f) cmd_pwd_h = echo -n static const char default_passwd[] = \ $@; \ cat $ | tr -d '\n' $@; \ echo \; $@ include/generated/passwd.h: $(PASSWD_FILE) $(call if_changed,pwd_h) This would need to run the hash/pbkdf2 and store salt+key. 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: [PATCH 07/10] password: add pbkdf2 support
On 12:05 Mon 16 Mar , Jan Lübbe wrote: On Mo, 2015-03-16 at 12:01 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 11:49 Mon 16 Mar , Jan Lübbe wrote: On Mo, 2015-03-16 at 11:15 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: We will use barebox_password as salt and 1 round to generate a 64 bytes key. The purpose of a salt is to protect a against dictionary or rainbow-table (precomputed) attacks. That means that the Salt must be randomly generated and saved with the password. This will be a enough stong enven with static one to protect against reverse hack for barebox protection Use a 32 byte pass try to do an attack agaist dictionary. it will take you more than 10 years to break it For setting a new password in barebox, even a low entropy salt will make attacks significantly more expensive. So we should add some entropy from user interaction timing in that case. yes we could do this too For hashing a password at compile time, we should get the salt from the host system. yes do we really need it? Yes, definitely. We must use the algorithms as they are intended to be used. If we try to move users away from RSA2048 because it will be vulnerable in the future, we should not go against established practice for password salts by hard-coding it. I'm not against it but with the barebox entropy did not see the point to use it. so how do we generate the salt? what length Personnaly I'll prefer a random 64 bytes | sha256 | take first 32bytes. | pbkdf2 1 round result a 64 bytes password file salt 32 byeskey 32 bytes 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 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 3/4] FIT: add FIT image support
On Mo, 2015-03-16 at 12:14 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 11:19 Mon 16 Mar , Jan Lübbe wrote: Later I'd like to have optional support to switch barebox into a non-secure or developer mode at runtime, which would make hardware secrets inaccessible. That could be triggered when a prompt appears or when booting for a different source (such as USB fastboot). yeah, I like the idea but for this will have to put a lot of protection so you can not read/write some part of the memory included barebox itself (in RAM) As in the kernel we have no memmory protection from the shell. Not necessarily. For example on the MX6 you can trigger a security violation in the CAAM from software. That will clear the OTPMK in its Key-RAM. From that point on you can run any software but you will not be able to decrypt any secret data which was encrypted with the OTPMK. On hardware which supports something like this, debugging hardware problems is easy and there is no danger of leaking any secret information. If something is useful/possible in any specific project obviously depends on the threat model and hardware capabilities. the main problem is not console but env you need to drop RW env support and use only RO one, except for keyring support where you will a RW env but not executable and only accesable by crypto API otherwise you need to use a secured digest such as HMAC/CMAC/OMAC support to sign the env at runtime and ensure the symetric key is secured or encrypt it via aes (did this in the past) For an upcoming project we'll add HMAC support to the state storage Marc recently submitted. I've a patch too I need to send it For environment or state storage? but I prefer to wait we have keystore support as this will store the key for the HMAC otherwise we need to use HW HMAC that store the key in the soc Another possibility is to use the HW AES key and a compiled in value to derive a per-device HMAC secret. The same approach can also be used in Linux for deriving the IMA/EVM HMAC secret. 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 3/4] FIT: add FIT image support
Hi Jean-Christophe, On Fr, 2015-03-13 at 17:08 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 16:41 Fri 13 Mar , Jan Lübbe wrote: On Fr, 2015-03-13 at 15:28 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: It's not the job of barebox to define security policies, it must fit well into the larger security design, which may require compromises. I disagree, disable by default non secure feature is require to pass secure boot certification Is there a specific certification you are targeting? yes but can not give details all under NDA, a book of more than 500 pages for bootloader/linux/kernel co OK, that's unfortunate. Still I'd like to have some documentation on the overall design of Barebox's verified boot. That doesn't mean you have to write it all by yourself. ;) How do you intend to handle console access in verified boot mode? Allowing access to md/mw would break any security. it's already mainline for month, check password support as I put it in production more than 1 years ago or simple disable input console all time, the code is here So currently we have: 1) use password 2) disable console Later I'd like to have optional support to switch barebox into a non-secure or developer mode at runtime, which would make hardware secrets inaccessible. That could be triggered when a prompt appears or when booting for a different source (such as USB fastboot). the main problem is not console but env you need to drop RW env support and use only RO one, except for keyring support where you will a RW env but not executable and only accesable by crypto API otherwise you need to use a secured digest such as HMAC/CMAC/OMAC support to sign the env at runtime and ensure the symetric key is secured or encrypt it via aes (did this in the past) For an upcoming project we'll add HMAC support to the state storage Marc recently submitted. ww may have to get secured malloac with part where the md/mw and any other API can not touch only the crypto API but this will be for later Yes. I'll send a patch to use the pbkdf2 for password Nice. 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: [PATCH 07/10] password: add pbkdf2 support
On 12:58 Mon 16 Mar , Jan Lübbe wrote: On Mo, 2015-03-16 at 12:52 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 12:41 Mon 16 Mar , Jan Lübbe wrote: On Mo, 2015-03-16 at 12:25 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: Yes, definitely. We must use the algorithms as they are intended to be used. If we try to move users away from RSA2048 because it will be vulnerable in the future, we should not go against established practice for password salts by hard-coding it. I'm not against it but with the barebox entropy did not see the point to use it. so how do we generate the salt? what length Personnaly I'll prefer a random 64 bytes | sha256 | take first 32bytes. | pbkdf2 1 round Running SHA-256 on random data is useless for security. SHA256 is to improve the entrpopy not security Running a deterministic algorithm cannot increase entropy (only reduce it). check the kennel algo for PRGN and youp will see why I want to use a sha Just get hash-size bytes from /dev/urandom on the host. We could generate a file with the compile-time SALT which is then included. On the running barebox, we could use SHA to hash the old password file together with the current timer value. At least until we have something better. result a 64 bytes password file salt 32 byeskey 32 bytes Yes. As we select the algorithm at compile time, we don't the to save it in the file. this is for barebox as we may not have any passwd file The same applies also to the default_passwd compiled in variable. Currently we have: PASSWD_FILE := $(shell cd $(srctree); find $(CONFIG_PASSWORD_DEFAULT) -type f) cmd_pwd_h = echo -n static const char default_passwd[] = \ $@; \ cat $ | tr -d '\n' $@; \ echo \; $@ include/generated/passwd.h: $(PASSWD_FILE) $(call if_changed,pwd_h) This would need to run the hash/pbkdf2 and store salt+key. no as the current current code expect you to give the correct file format for the currently use password so today the output of openssl but yes we may need to do more here Best Regards, J. ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 04/10] command: add generic digest command
On Mo, 2015-03-16 at 11:15 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: +BAREBOX_CMD_HELP_START(digest) +BAREBOX_CMD_HELP_TEXT(Calculate a digest over a FILE or a memory area.) +BAREBOX_CMD_HELP_TEXT(Options:) +BAREBOX_CMD_HELP_OPT (-a algo\t, digest to use) +BAREBOX_CMD_HELP_OPT (-k key\t, key as text) +BAREBOX_CMD_HELP_OPT (-K file\t, key file) +BAREBOX_CMD_HELP_OPT (-s sig\t, digest) +BAREBOX_CMD_HELP_OPT (-S file\t, digest flie) +BAREBOX_CMD_HELP_END We're mixing different terms here: digest and signature Signature is usually used in the context of public key crypto, digest is mostly used with for hashes. The command uses both interchangeably. How about: -a algo hash or signature algorithm to use -k keyuse supplied key (ASCII or hex) for MAC -K file use key from file (binary) for MAC -v hexverify data against supplied hex (hash, MAC or signature) -V file verify data against file (hash, MAC or signature) 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
[PATCH 05/10] digest: add digest callback
Combination of @init and @update and @final. This function
effectively behaves as the entire chain of operations, @init,
@update and @final issued in sequence. This is added for hardware
which cannot do even the @finup, but can only do the whole
transformation in one run.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
crypto/digest.c | 18 ++
crypto/hmac.c | 1 +
crypto/internal.h | 2 ++
crypto/md5.c | 1 +
crypto/sha1.c | 1 +
crypto/sha2.c | 1 +
crypto/sha4.c | 1 +
include/digest.h | 8
8 files changed, 33 insertions(+)
diff --git a/crypto/digest.c b/crypto/digest.c
index 9fa5bba..c261f7e 100644
--- a/crypto/digest.c
+++ b/crypto/digest.c
@@ -58,6 +58,24 @@ end:
return ret;
}
+int digest_generic_digest(struct digest *d, const void *data,
+ unsigned int len, u8 *md)
+
+{
+ int ret;
+
+ if (!data || len == 0 || !md)
+ return -EINVAL;
+
+ ret = digest_init(d);
+ if (ret)
+ return ret;
+ ret = digest_update(d, data, len);
+ if (ret)
+ return ret;
+ return digest_final(d, md);
+}
+
int digest_algo_register(struct digest_algo *d)
{
if (!d || !d-name || !d-update || !d-final || !d-verify ||
diff --git a/crypto/hmac.c b/crypto/hmac.c
index f39e4c8..b1c17af 100644
--- a/crypto/hmac.c
+++ b/crypto/hmac.c
@@ -136,6 +136,7 @@ struct digest_algo hmac_algo = {
.init = digest_hmac_init,
.update = digest_hmac_update,
.final = digest_hmac_final,
+ .digest = digest_generic_digest,
.verify = digest_generic_verify,
.set_key = digest_hmac_set_key,
.free = digest_hmac_free,
diff --git a/crypto/internal.h b/crypto/internal.h
index f482654..c6f5908 100644
--- a/crypto/internal.h
+++ b/crypto/internal.h
@@ -15,3 +15,5 @@ static inline int digest_hmac_register(struct digest_algo
*algo,
#endif
int digest_generic_verify(struct digest *d, const unsigned char *md);
+int digest_generic_digest(struct digest *d, const void *data,
+ unsigned int len, u8 *out);
diff --git a/crypto/md5.c b/crypto/md5.c
index 4847b38..b7ad6f2 100644
--- a/crypto/md5.c
+++ b/crypto/md5.c
@@ -294,6 +294,7 @@ static struct digest_algo md5 = {
.init = digest_md5_init,
.update = digest_md5_update,
.final = digest_md5_final,
+ .digest = digest_generic_digest,
.verify = digest_generic_verify,
.length = 16,
.ctx_length = sizeof(struct MD5Context),
diff --git a/crypto/sha1.c b/crypto/sha1.c
index 09dee87..b108f8a 100644
--- a/crypto/sha1.c
+++ b/crypto/sha1.c
@@ -315,6 +315,7 @@ static struct digest_algo m = {
.init = digest_sha1_init,
.update = digest_sha1_update,
.final = digest_sha1_final,
+ .digest = digest_generic_digest,
.verify = digest_generic_verify,
.length = SHA1_SUM_LEN,
.ctx_length = sizeof(sha1_context),
diff --git a/crypto/sha2.c b/crypto/sha2.c
index 9bf6541..375a40e 100644
--- a/crypto/sha2.c
+++ b/crypto/sha2.c
@@ -336,6 +336,7 @@ static struct digest_algo m256 = {
.init = digest_sha256_init,
.update = digest_sha2_update,
.final = digest_sha2_final,
+ .digest = digest_generic_digest,
.verify = digest_generic_verify,
.length = SHA256_SUM_LEN,
.ctx_length = sizeof(sha2_context),
diff --git a/crypto/sha4.c b/crypto/sha4.c
index 5c3097d..1b91e7f 100644
--- a/crypto/sha4.c
+++ b/crypto/sha4.c
@@ -342,6 +342,7 @@ static struct digest_algo m512 = {
.init = digest_sha512_init,
.update = digest_sha4_update,
.final = digest_sha4_final,
+ .digest = digest_generic_digest,
.verify = digest_generic_verify,
.length = SHA512_SUM_LEN,
.ctx_length = sizeof(sha4_context),
diff --git a/include/digest.h b/include/digest.h
index ec904f0..8250ca7 100644
--- a/include/digest.h
+++ b/include/digest.h
@@ -31,6 +31,8 @@ struct digest_algo {
int (*init)(struct digest *d);
int (*update)(struct digest *d, const void *data, unsigned long len);
int (*final)(struct digest *d, unsigned char *md);
+ int (*digest)(struct digest *d, const void *data,
+ unsigned int len, u8 *out);
int (*set_key)(struct digest *d, const unsigned char *key, unsigned int
len);
int (*verify)(struct digest *d, const unsigned char *md);
@@ -85,6 +87,12 @@ static inline int digest_final(struct digest *d, unsigned
char *md)
return d-algo-final(d, md);
}
+static inline int digest_digest(struct digest *d, const void *data,
+ unsigned int len, u8 *md)
+{
+ return d-algo-digest(d, data, len, md);
+}
+
static inline int digest_verify(struct digest *d, const unsigned char *md)
{
return d-algo-verify(d, md);
--
2.1.4
___
barebox mailing list
[PATCH 01/10] digest: add verify callback
this will allow to compare a md with the original one
When calling this do not call final
For RSA_SIGN verification final does not exist only verify
as final will be for signing
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
crypto/digest.c | 24 +++-
crypto/hmac.c | 1 +
crypto/internal.h | 2 ++
crypto/md5.c | 1 +
crypto/sha1.c | 1 +
crypto/sha2.c | 2 ++
crypto/sha4.c | 2 ++
include/digest.h | 6 ++
8 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/crypto/digest.c b/crypto/digest.c
index c06089d..52e8796 100644
--- a/crypto/digest.c
+++ b/crypto/digest.c
@@ -26,6 +26,8 @@
#include module.h
#include linux/err.h
+#include internal.h
+
static LIST_HEAD(digests);
static struct digest_algo *digest_algo_get_by_name(const char *name);
@@ -37,9 +39,29 @@ static int dummy_init(struct digest *d)
static void dummy_free(struct digest *d) {}
+int digest_generic_verify(struct digest *d, const unsigned char *md)
+{
+ int ret;
+ int len = digest_length(d);
+ unsigned char *tmp;
+
+ tmp = xmalloc(len);
+
+ ret = digest_final(d, tmp);
+ if (ret)
+ goto end;
+
+ ret = memcmp(md, tmp, len);
+ ret = ret ? -EINVAL : 0;
+end:
+ free(tmp);
+ return ret;
+}
+
int digest_algo_register(struct digest_algo *d)
{
- if (!d || !d-name || !d-update || !d-final || d-length 1)
+ if (!d || !d-name || !d-update || !d-final || !d-verify ||
+ d-length 1)
return -EINVAL;
if (!d-init)
diff --git a/crypto/hmac.c b/crypto/hmac.c
index 1462730..f39e4c8 100644
--- a/crypto/hmac.c
+++ b/crypto/hmac.c
@@ -136,6 +136,7 @@ struct digest_algo hmac_algo = {
.init = digest_hmac_init,
.update = digest_hmac_update,
.final = digest_hmac_final,
+ .verify = digest_generic_verify,
.set_key = digest_hmac_set_key,
.free = digest_hmac_free,
.ctx_length = sizeof(struct digest_hmac),
diff --git a/crypto/internal.h b/crypto/internal.h
index cc409d8..f482654 100644
--- a/crypto/internal.h
+++ b/crypto/internal.h
@@ -13,3 +13,5 @@ static inline int digest_hmac_register(struct digest_algo
*algo,
return 0;
}
#endif
+
+int digest_generic_verify(struct digest *d, const unsigned char *md);
diff --git a/crypto/md5.c b/crypto/md5.c
index fe17ff5..4847b38 100644
--- a/crypto/md5.c
+++ b/crypto/md5.c
@@ -294,6 +294,7 @@ static struct digest_algo md5 = {
.init = digest_md5_init,
.update = digest_md5_update,
.final = digest_md5_final,
+ .verify = digest_generic_verify,
.length = 16,
.ctx_length = sizeof(struct MD5Context),
};
diff --git a/crypto/sha1.c b/crypto/sha1.c
index a244b5d..09dee87 100644
--- a/crypto/sha1.c
+++ b/crypto/sha1.c
@@ -315,6 +315,7 @@ static struct digest_algo m = {
.init = digest_sha1_init,
.update = digest_sha1_update,
.final = digest_sha1_final,
+ .verify = digest_generic_verify,
.length = SHA1_SUM_LEN,
.ctx_length = sizeof(sha1_context),
};
diff --git a/crypto/sha2.c b/crypto/sha2.c
index cb89c82..9bf6541 100644
--- a/crypto/sha2.c
+++ b/crypto/sha2.c
@@ -304,6 +304,7 @@ static struct digest_algo m224 = {
.init = digest_sha224_init,
.update = digest_sha2_update,
.final = digest_sha2_final,
+ .verify = digest_generic_verify,
.length = SHA224_SUM_LEN,
.ctx_length = sizeof(sha2_context),
};
@@ -335,6 +336,7 @@ static struct digest_algo m256 = {
.init = digest_sha256_init,
.update = digest_sha2_update,
.final = digest_sha2_final,
+ .verify = digest_generic_verify,
.length = SHA256_SUM_LEN,
.ctx_length = sizeof(sha2_context),
};
diff --git a/crypto/sha4.c b/crypto/sha4.c
index 1c768e7..5c3097d 100644
--- a/crypto/sha4.c
+++ b/crypto/sha4.c
@@ -309,6 +309,7 @@ static struct digest_algo m384 = {
.init = digest_sha384_init,
.update = digest_sha4_update,
.final = digest_sha4_final,
+ .verify = digest_generic_verify,
.length = SHA384_SUM_LEN,
.ctx_length = sizeof(sha4_context),
};
@@ -341,6 +342,7 @@ static struct digest_algo m512 = {
.init = digest_sha512_init,
.update = digest_sha4_update,
.final = digest_sha4_final,
+ .verify = digest_generic_verify,
.length = SHA512_SUM_LEN,
.ctx_length = sizeof(sha4_context),
};
diff --git a/include/digest.h b/include/digest.h
index b890a7a..cba7814 100644
--- a/include/digest.h
+++ b/include/digest.h
@@ -32,6 +32,7 @@ struct digest_algo {
int (*update)(struct digest *d, const void *data, unsigned long len);
int (*final)(struct digest *d, unsigned char *md);
int (*set_key)(struct digest *d, const unsigned char *key, unsigned int
len);
+ int (*verify)(struct digest *d, const unsigned char *md);
unsigned int
[PATCH 08/10] digest: allow algo to specify their length at runtime
such as RSA as we load a DER key we will detect the key size
at runtime and so the algo length.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
include/digest.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/digest.h b/include/digest.h
index 8250ca7..41ad912 100644
--- a/include/digest.h
+++ b/include/digest.h
@@ -45,6 +45,7 @@ struct digest_algo {
struct digest {
struct digest_algo *algo;
void *ctx;
+ unsigned int length;
};
/*
@@ -100,7 +101,7 @@ static inline int digest_verify(struct digest *d, const
unsigned char *md)
static inline int digest_length(struct digest *d)
{
- return d-algo-length;
+ return d-length ? d-length : d-algo-length;
}
static inline int digest_set_key(struct digest *d, const unsigned char *key,
--
2.1.4
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
[PATCH 04/10] command: add generic digest command
That can be used for digest calculation and verify
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
commands/Kconfig| 12 +++-
commands/Makefile | 1 +
commands/digest.c | 193
commands/hashsum.c | 68 --
commands/internal.h | 3 +
crypto/digest.c | 25 +--
include/digest.h| 8 ++-
7 files changed, 248 insertions(+), 62 deletions(-)
create mode 100644 commands/digest.c
create mode 100644 commands/internal.h
diff --git a/commands/Kconfig b/commands/Kconfig
index 7e3e8b7..847ff76 100644
--- a/commands/Kconfig
+++ b/commands/Kconfig
@@ -14,7 +14,7 @@ if COMMAND_SUPPORT
config COMPILE_HASH
tristate
- select DIGEST
+ select CMD_DIGEST
help
Turns on compilation of digest.c
@@ -842,6 +842,16 @@ config CMD_CMP
Returns successfully if the two files are the same, return with an
error if not
+config CMD_DIGEST
+ tristate
+ select DIGEST
+ prompt digest
+ help
+ Usage: digest -a algo [-k key | -K file] [-s sig | -S file]
FILE|AREA
+
+ Calculate a digest over a FILE or a memory area with the possibility
+ to checkit.
+
config CMD_DIRNAME
tristate
prompt dirname
diff --git a/commands/Makefile b/commands/Makefile
index e42662f..b902f58 100644
--- a/commands/Makefile
+++ b/commands/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_STDDEV) += stddev.o
+obj-$(CONFIG_CMD_DIGEST) += digest.o
obj-$(CONFIG_COMPILE_HASH) += hashsum.o
obj-$(CONFIG_COMPILE_MEMORY) += mem.o
obj-$(CONFIG_CMD_BOOTM)+= bootm.o
diff --git a/commands/digest.c b/commands/digest.c
new file mode 100644
index 000..2569975
--- /dev/null
+++ b/commands/digest.c
@@ -0,0 +1,193 @@
+/*
+ * Copyright (c) 2015 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
+ *
+ * GPLv2 ONLY
+ */
+
+#include common.h
+#include command.h
+#include fs.h
+#include fcntl.h
+#include errno.h
+#include xfuncs.h
+#include malloc.h
+#include digest.h
+#include getopt.h
+#include libfile.h
+
+#include internal.h
+
+int __do_digest(struct digest *d, unsigned char *key, int keylen,
+ unsigned char *sig,
+ int argc, char *argv[])
+{
+ int ret = 0;
+ int i;
+ unsigned char *hash;
+
+ if (argc 1)
+ return COMMAND_ERROR_USAGE;
+
+ hash = calloc(digest_length(d), sizeof(unsigned char));
+ if (!hash) {
+ perror(calloc);
+ return COMMAND_ERROR_USAGE;
+ }
+
+ while (*argv) {
+ char *filename = /dev/mem;
+ loff_t start = 0, size = ~0;
+
+ /* arguments are either file, file+area or area */
+ if (parse_area_spec(*argv, start, size)) {
+ filename = *argv;
+ if (argv[1] !parse_area_spec(argv[1], start, size))
+ argv++;
+ }
+
+ ret = digest_file_window(d, filename,
+key, keylen,
+hash, sig, start, size);
+ if (ret 0) {
+ ret = 1;
+ } else {
+ if (!sig) {
+ for (i = 0; i digest_length(d); i++)
+ printf(%02x, hash[i]);
+
+ printf( %s\t0x%08llx ... 0x%08llx\n,
+ filename, start, start + size);
+ }
+ }
+
+ argv++;
+ }
+
+ free(hash);
+ digest_free(d);
+
+ return ret;
+}
+
+static void prints_algo_help(void)
+{
+ puts(\navailable algo:\n);
+ digest_algo_prints(\t);
+}
+
+static int do_digest(int argc, char *argv[])
+{
+ struct digest *d;
+ unsigned char *tmp_key = NULL;
+ unsigned char *tmp_sig = NULL;
+ char *sig = NULL;
+ char *sigfile = NULL;
+ size_t siglen = 0;
+ char *key = NULL;
+ char *keyfile = NULL;
+ size_t keylen = 0;
+ size_t digestlen = 0;
+ char *algo = NULL;
+ int opt, ret;
+
+ if (argc 2)
+ return COMMAND_ERROR_USAGE;
+
+ while((opt = getopt(argc, argv, a:k:K:s:S:)) 0) {
+ switch(opt) {
+ case 'k':
+ key = optarg;
+ keylen = strlen(key);
+ break;
+ case 'K':
+ keyfile = optarg;
+ break;
+ case 'a':
+ algo = optarg;
+ break;
+ case 's':
+ sig = optarg;
+ siglen = strlen(sig);
+ break;
+ case 'S':
+ sigfile = optarg;
+
[PATCH 06/10] crypto: add pbkdf2 hmac key generator
this will allow to generate a KEY + IV based on a password and salt for AES
encryption/decryption as example
or simply the key for hmac or rsa from text password
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
crypto/Kconfig | 5 +++
crypto/Makefile | 2 ++
crypto/pbkdf2.c | 94 +
include/crypto/pbkdf2.h | 23
4 files changed, 124 insertions(+)
create mode 100644 crypto/pbkdf2.c
create mode 100644 include/crypto/pbkdf2.h
diff --git a/crypto/Kconfig b/crypto/Kconfig
index e72b91e..b721e30 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -34,3 +34,8 @@ config DIGEST_HMAC
bool HMAC
endif
+
+config CRYPTO_PBKDF2
+ select DIGEST
+ select SHA1
+ bool
diff --git a/crypto/Makefile b/crypto/Makefile
index ff5c289..0bb67d5 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -9,3 +9,5 @@ obj-$(CONFIG_SHA224)+= sha2.o
obj-$(CONFIG_SHA256) += sha2.o
obj-$(CONFIG_SHA384) += sha4.o
obj-$(CONFIG_SHA512) += sha4.o
+
+obj-$(CONFIG_CRYPTO_PBKDF2)+= pbkdf2.o
diff --git a/crypto/pbkdf2.c b/crypto/pbkdf2.c
new file mode 100644
index 000..c4ba7be
--- /dev/null
+++ b/crypto/pbkdf2.c
@@ -0,0 +1,94 @@
+/*
+ * (C) Copyright 2015 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
+ *
+ * Under GPLv2 Only
+ */
+
+#include common.h
+#include malloc.h
+#include errno.h
+#include crypto/pbkdf2.h
+
+int pkcs5_pbkdf2_hmac(struct digest* d,
+ const unsigned char *pwd, size_t pwd_len,
+ const unsigned char *salt, size_t salt_len,
+ uint32_t iteration,
+ uint32_t key_len, unsigned char *key)
+{
+ int i, j, k;
+ unsigned char cnt[4];
+ uint32_t pass_len;
+ unsigned char *tmpdgt;
+ uint32_t d_len;
+ int ret;
+
+ if (!d)
+ return -EINVAL;
+
+ d_len = digest_length(d);
+ tmpdgt = malloc(d_len);
+ if (!tmpdgt)
+ return -ENOMEM;
+
+ i = 1;
+
+ ret = digest_set_key(d, pwd, pwd_len);
+ if (ret)
+ goto err;
+
+ while (key_len) {
+ pass_len = min(key_len, d_len);
+ cnt[0] = (i 24) 0xff;
+ cnt[1] = (i 16) 0xff;
+ cnt[2] = (i 8) 0xff;
+ cnt[3] = i 0xff;
+ ret = digest_init(d);
+ if (ret)
+ goto err;
+ ret = digest_update(d, salt, salt_len);
+ if (ret)
+ goto err;
+ ret = digest_update(d, cnt, 4);
+ if (ret)
+ goto err;
+ ret = digest_final(d, tmpdgt);
+ if (ret)
+ goto err;
+
+ memcpy(key, tmpdgt, pass_len);
+
+ for (j = 1; j iteration; j++) {
+ ret = digest_digest(d, tmpdgt, d_len, tmpdgt);
+ if (ret)
+ goto err;
+
+ for(k = 0; k pass_len; k++)
+ key[k] ^= tmpdgt[k];
+ }
+
+ key_len -= pass_len;
+ key += pass_len;
+ i++;
+ }
+
+ ret = 0;
+err:
+ free(tmpdgt);
+
+ return ret;;
+}
+
+int pkcs5_pbkdf2_hmac_sha1(const unsigned char *pwd, size_t pwd_len,
+ const unsigned char *salt, size_t salt_len,
+ uint32_t iter,
+ uint32_t key_len, unsigned char *key)
+{
+ int ret;
+ struct digest* d = digest_alloc(hmac(sha1));
+
+ ret = pkcs5_pbkdf2_hmac(d, pwd, pwd_len, salt, salt_len, iter,
+key_len, key);
+
+ digest_free(d);
+ return ret;
+}
diff --git a/include/crypto/pbkdf2.h b/include/crypto/pbkdf2.h
new file mode 100644
index 000..fa66675
--- /dev/null
+++ b/include/crypto/pbkdf2.h
@@ -0,0 +1,23 @@
+/*
+ * (C) Copyright 2015 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
+ *
+ * Under GPLv2 Only
+ */
+
+#ifndef __PBKDF2_H__
+#define __PBKDF2_H__
+
+#include digest.h
+
+int pkcs5_pbkdf2_hmac_sha1(const unsigned char *pwd, size_t pwd_len,
+ const unsigned char *salt, size_t salt_len,
+ uint32_t iteration,
+ uint32_t key_len, unsigned char *buf);
+
+int pkcs5_pbkdf2_hmac(struct digest* d,
+ const unsigned char *pwd, size_t pwd_len,
+ const unsigned char *salt, size_t salt_len,
+ uint32_t iteration,
+ uint32_t key_len, unsigned char *key);
+
+#endif /* __PBKDF2_H__ */
--
2.1.4
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
[PATCH 10/10] digest: digest_file_window: check every digest_xxx return
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
crypto/digest.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/crypto/digest.c b/crypto/digest.c
index c261f7e..ee1a321 100644
--- a/crypto/digest.c
+++ b/crypto/digest.c
@@ -178,7 +178,9 @@ int digest_file_window(struct digest *d, const char
*filename,
if (key)
digest_set_key(d, key, keylen);
- digest_init(d);
+ ret = digest_init(d);
+ if (ret)
+ return ret;
fd = open(filename, O_RDONLY);
if (fd 0) {
@@ -222,7 +224,9 @@ int digest_file_window(struct digest *d, const char
*filename,
goto out_free;
}
- digest_update(d, buf, now);
+ ret = digest_update(d, buf, now);
+ if (ret)
+ goto out_free;
size -= now;
len += now;
}
@@ -230,7 +234,7 @@ int digest_file_window(struct digest *d, const char
*filename,
if (sig)
ret = digest_verify(d, sig);
else
- digest_final(d, hash);
+ ret = digest_final(d, hash);
out_free:
if (flags)
--
2.1.4
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
[PATCH 03/10] command: allow runtime usage
This will allow as example to list the currently supported digest.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
common/command.c | 2 ++
include/command.h | 3 +++
2 files changed, 5 insertions(+)
diff --git a/common/command.c b/common/command.c
index 61191c2..dc2cb88 100644
--- a/common/command.c
+++ b/common/command.c
@@ -47,6 +47,8 @@ void barebox_cmd_usage(struct command *cmdtp)
puts(cmdtp-help);
putchar('\n');
}
+ if (cmdtp-usage)
+ cmdtp-usage();
#endif
}
EXPORT_SYMBOL(barebox_cmd_usage);
diff --git a/include/command.h b/include/command.h
index 5d5bf53..3aca1a9 100644
--- a/include/command.h
+++ b/include/command.h
@@ -54,6 +54,7 @@ struct command {
uint32_tgroup;
#ifdef CONFIG_LONGHELP
const char *help; /* Help message(long) */
+ void(*usage)(void);
#endif
}
#ifdef __x86_64__
@@ -115,8 +116,10 @@ static const __maybe_unused char cmd_##_name##_help[] =
#ifdef CONFIG_LONGHELP
#define BAREBOX_CMD_HELP(text) .help = text,
+#define BAREBOX_CMD_USAGE(fn) .usage = fn,
#else
#define BAREBOX_CMD_HELP(text)
+#define BAREBOX_CMD_USAGE(fn)
#endif
#define BAREBOX_CMD_GROUP(grp) .group = grp,
--
2.1.4
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
[PATCH 09/10] crypto: hmac: use digest_digest and check the return of every digest_xxx
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
crypto/hmac.c | 49 +++--
1 file changed, 31 insertions(+), 18 deletions(-)
diff --git a/crypto/hmac.c b/crypto/hmac.c
index b1c17af..c2195d9 100644
--- a/crypto/hmac.c
+++ b/crypto/hmac.c
@@ -62,15 +62,15 @@ static int digest_hmac_set_key(struct digest *d, const
unsigned char *key,
{
struct digest_hmac_ctx *dh = d-ctx;
struct digest_hmac *hmac = to_digest_hmac(d-algo);
+ unsigned char *sum = NULL;
+ int ret;
free(dh-key);
if (len hmac-pad_length) {
- unsigned char *sum;
-
sum = xmalloc(digest_length(dh-d));
- digest_init(dh-d);
- digest_update(dh-d, dh-key, dh-keylen);
- digest_final(dh-d, sum);
+ ret = digest_digest(dh-d, dh-key, dh-keylen, sum);
+ if (ret)
+ goto err;
dh-keylen = digest_length(dh-d);
dh-key = sum;
} else {
@@ -79,14 +79,17 @@ static int digest_hmac_set_key(struct digest *d, const
unsigned char *key,
dh-keylen = len;
}
- return 0;
+ ret = 0;
+err:
+ free(sum);
+ return ret;
}
static int digest_hmac_init(struct digest *d)
{
struct digest_hmac_ctx *dh = d-ctx;
struct digest_hmac *hmac = to_digest_hmac(d-algo);
- int i;
+ int i, ret;
unsigned char *key = dh-key;
unsigned int keylen = dh-keylen;
@@ -98,10 +101,10 @@ static int digest_hmac_init(struct digest *d)
dh-opad[i] = (unsigned char)(dh-opad[i] ^ key[i]);
}
- digest_init(dh-d);
- digest_update(dh-d, dh-ipad, hmac-pad_length);
-
- return 0;
+ ret = digest_init(dh-d);
+ if (ret)
+ return ret;
+ return digest_update(dh-d, dh-ipad, hmac-pad_length);
}
static int digest_hmac_update(struct digest *d, const void *data,
@@ -117,18 +120,28 @@ static int digest_hmac_final(struct digest *d, unsigned
char *md)
struct digest_hmac_ctx *dh = d-ctx;
struct digest_hmac *hmac = to_digest_hmac(d-algo);
unsigned char *tmp = NULL;
+ int ret;
tmp = xmalloc(digest_length(d));
- digest_final(dh-d, tmp);
- digest_init(dh-d);
- digest_update(dh-d, dh-opad, hmac-pad_length);
- digest_update(dh-d, tmp, digest_length(d));
- digest_final(dh-d, md);
-
+ ret = digest_final(dh-d, tmp);
+ if (ret)
+ goto err;
+ ret = digest_init(dh-d);
+ if (ret)
+ goto err;
+ ret = digest_update(dh-d, dh-opad, hmac-pad_length);
+ if (ret)
+ goto err;
+ ret = digest_update(dh-d, tmp, digest_length(d));
+ if (ret)
+ goto err;
+ ret = digest_final(dh-d, md);
+
+err:
free(tmp);
- return 0;
+ return ret;
}
struct digest_algo hmac_algo = {
--
2.1.4
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 07/10] password: add pbkdf2 support
On 11:49 Mon 16 Mar , Jan Lübbe wrote: On Mo, 2015-03-16 at 11:15 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: We will use barebox_password as salt and 1 round to generate a 64 bytes key. The purpose of a salt is to protect a against dictionary or rainbow-table (precomputed) attacks. That means that the Salt must be randomly generated and saved with the password. This will be a enough stong enven with static one to protect against reverse hack for barebox protection Use a 32 byte pass try to do an attack agaist dictionary. it will take you more than 10 years to break it For setting a new password in barebox, even a low entropy salt will make attacks significantly more expensive. So we should add some entropy from user interaction timing in that case. yes we could do this too For hashing a password at compile time, we should get the salt from the host system. yes do we really need it? 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 ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 07/10] password: add pbkdf2 support
On Mo, 2015-03-16 at 12:25 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: Yes, definitely. We must use the algorithms as they are intended to be used. If we try to move users away from RSA2048 because it will be vulnerable in the future, we should not go against established practice for password salts by hard-coding it. I'm not against it but with the barebox entropy did not see the point to use it. so how do we generate the salt? what length Personnaly I'll prefer a random 64 bytes | sha256 | take first 32bytes. | pbkdf2 1 round Running SHA-256 on random data is useless for security. Just get hash-size bytes from /dev/urandom on the host. We could generate a file with the compile-time SALT which is then included. On the running barebox, we could use SHA to hash the old password file together with the current timer value. At least until we have something better. result a 64 bytes password file salt 32 byeskey 32 bytes Yes. As we select the algorithm at compile time, we don't the to save it in the file. 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 3/4] FIT: add FIT image support
On Mo, 2015-03-16 at 15:40 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 15:31 Mon 16 Mar , Jan Lübbe wrote: (The following depends on prohibiting any unauthenticated access to the barebox console.) If you just use a chain of signed code like with HAB on i.MX, every cert is verified by the previous step (up to the SRK table hash), so there is no need to additionally protect certs against modification. Any modified cert would result in a verification error. In this setup there is no secret information on the device at all. When doing this without support from the SoC's ROM code, you could store barebox (with compiled-in master public key(s)) in RO flash. Against an attacker without physical access, this results in the same security properties. You couldn't update the RO barebox, tough (only boot another one second stage). I agree with you I said the same my key point is if we do allow console access we need be sure at 100% that they can not tempered with the trusted key in RAM and barebox binary and malloc space Yes. We would also need to disallow access to devices and non-verifying boot commands. 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: [PATCH] net: ping: return an error exit code when connection fails
Il 2015-03-16 16:02 Mirko Damiani ha scritto:
Hi,
ping command does not always returns 1 as exit code when connection to
host fails.
In particular it returns the exit code of the previous run.
This patch fixes this issue.
Sorry, the same patch with proper tabulation characters.
Signed-off-by: Mirko Damiani mi...@develer.com
---
net/ping.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ping.c b/net/ping.c
index 2349f4b..4eb77cb 100644
--- a/net/ping.c
+++ b/net/ping.c
@@ -67,6 +67,9 @@ static int do_ping(int argc, char *argv[])
return 1;
}
+ ping_state = PING_STATE_INIT;
+ ping_sequence_number = 0;
+
ping_con = net_icmp_new(net_ping_ip, ping_handler, NULL);
if (IS_ERR(ping_con)) {
ret = PTR_ERR(ping_con);
@@ -78,9 +81,6 @@ static int do_ping(int argc, char *argv[])
if (ret)
goto out_unreg;
- ping_state = PING_STATE_INIT;
- ping_sequence_number = 0;
-
while (ping_state == PING_STATE_INIT) {
if (ctrlc()) {
ret = -EINTR;
--
1.9.1
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [RFC 3/4] FIT: add FIT image support
On 15:31 Mon 16 Mar , Jan Lübbe wrote: On Mo, 2015-03-16 at 14:51 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: The other pb I see is this one where and do you plan to store the RO x509 the trusted one. Sorry, I can't parse this. where do we store the trusted keys/cert need to be secured or inaccessible except crypto API (The following depends on prohibiting any unauthenticated access to the barebox console.) If you just use a chain of signed code like with HAB on i.MX, every cert is verified by the previous step (up to the SRK table hash), so there is no need to additionally protect certs against modification. Any modified cert would result in a verification error. In this setup there is no secret information on the device at all. When doing this without support from the SoC's ROM code, you could store barebox (with compiled-in master public key(s)) in RO flash. Against an attacker without physical access, this results in the same security properties. You couldn't update the RO barebox, tough (only boot another one second stage). I agree with you I said the same my key point is if we do allow console access we need be sure at 100% that they can not tempered with the trusted key in RAM and barebox binary and malloc space 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
[PATCH] net: ping: return an error exit code when connection fails
Hi,
ping command does not always returns 1 as exit code when connection to
host fails.
In particular it returns the exit code of the previous run.
This patch fixes this issue.
Signed-off-by: Mirko Damiani mi...@develer.com
---
net/ping.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ping.c b/net/ping.c
index 2349f4b..4eb77cb 100644
--- a/net/ping.c
+++ b/net/ping.c
@@ -67,6 +67,9 @@ static int do_ping(int argc, char *argv[])
return 1;
}
+ping_state = PING_STATE_INIT;
+ping_sequence_number = 0;
+
ping_con = net_icmp_new(net_ping_ip, ping_handler, NULL);
if (IS_ERR(ping_con)) {
ret = PTR_ERR(ping_con);
@@ -78,9 +81,6 @@ static int do_ping(int argc, char *argv[])
if (ret)
goto out_unreg;
-ping_state = PING_STATE_INIT;
-ping_sequence_number = 0;
-
while (ping_state == PING_STATE_INIT) {
if (ctrlc()) {
ret = -EINTR;
--
1.9.1
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
[PATCH 00/10 v3] prepare for rsa support
Hi, The following patch series prepare for the adding of the rsa digest support This will allow to verify a rsa signature of a file Introduction of a new command digest to handle the digest and check The next patch series will add RSA and keystore support v2: - rebase on next - add pbkdf2 to password/login framework - command allow to have runtime output used it in the new digest to print the supported algo v3: add more fix to ensure all the digest_xx call return are checked The following changes since commit bbba2d05585637d04657dce293c0cb0611dbfeea: Merge branch 'for-next/state' into next (2015-03-13 08:32:38 +0100) are available in the git repository at: git://git.jcrosoft.org/barebox.git delivery/digest for you to fetch changes up to e4ec247ea29b5b48386f6a959f96f78d9cef729b: digest: digest_file_window: check every digest_xxx return (2015-03-14 11:08:05 +0800) Jean-Christophe PLAGNIOL-VILLARD (10): digest: add verify callback command: rename digest.c to hashsum.c command: allow runtime usage command: add generic digest command digest: add digest callback crypto: add pbkdf2 hmac key generator password: add pbkdf2 support digest: allow algo to specify their length at runtime crypto: hmac: use digest_digest and check the return of every digest_xxx digest: digest_file_window: check every digest_xxx return commands/Kconfig| 26 +-- commands/Makefile | 3 ++- commands/digest.c | 268 +++--- commands/hashsum.c | 187 commands/internal.h | 3 +++ common/Kconfig | 4 +++ common/command.c| 2 ++ common/password.c | 79 crypto/Kconfig | 5 crypto/Makefile | 2 ++ crypto/digest.c | 75 +++-- crypto/hmac.c | 51 +++- crypto/internal.h | 4 +++ crypto/md5.c| 2 ++ crypto/pbkdf2.c | 94 +++ crypto/sha1.c | 2 ++ crypto/sha2.c | 3 +++ crypto/sha4.c | 3 +++ include/command.h | 3 +++ include/crypto/pbkdf2.h | 23 + include/digest.h| 25 +++--- 21 files changed, 647 insertions(+), 217 deletions(-) create mode 100644 commands/hashsum.c create mode 100644 commands/internal.h create mode 100644 crypto/pbkdf2.c create mode 100644 include/crypto/pbkdf2.h 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 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: [PATCH 07/10] password: add pbkdf2 support
On Mo, 2015-03-16 at 11:15 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: We will use barebox_password as salt and 1 round to generate a 64 bytes key. The purpose of a salt is to protect a against dictionary or rainbow-table (precomputed) attacks. That means that the Salt must be randomly generated and saved with the password. For setting a new password in barebox, even a low entropy salt will make attacks significantly more expensive. So we should add some entropy from user interaction timing in that case. For hashing a password at compile time, we should get the salt from the host system. 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: [PATCH 8/8] command: add hmac sum supportfor md5, sha1, sha224, sha256, sha384, sha512
On Mi, 2015-03-11 at 17:53 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: diff --git a/include/digest.h b/include/digest.h index a26848c..fd47a7e 100644 --- a/include/digest.h +++ b/include/digest.h @@ -54,11 +54,14 @@ struct digest *digest_alloc(char* name); void digest_free(struct digest *d); int digest_file_window(struct digest *d, char *filename, + unsigned char *key, size_t keylen, unsigned char *hash, ulong start, ulong size); int digest_file(struct digest *d, char *filename, + unsigned char *key, size_t keylen, unsigned char *hash); This is already in next, but I'd like to know why you added the key/keylen args to each function instead of letting the caller use digest_set_key()? In the patch [PATCH 04/10] command: add generic digest command you add another parameter (unsigned char *sig) to these functions, which is used instead of the key parameter when verifying. Maybe we are overloading them with to much different functionality? 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 3/4] FIT: add FIT image support
On 13:08 Mon 16 Mar , Jan Lübbe wrote: On Mo, 2015-03-16 at 12:14 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 11:19 Mon 16 Mar , Jan Lübbe wrote: Later I'd like to have optional support to switch barebox into a non-secure or developer mode at runtime, which would make hardware secrets inaccessible. That could be triggered when a prompt appears or when booting for a different source (such as USB fastboot). yeah, I like the idea but for this will have to put a lot of protection so you can not read/write some part of the memory included barebox itself (in RAM) As in the kernel we have no memmory protection from the shell. Not necessarily. For example on the MX6 you can trigger a security violation in the CAAM from software. That will clear the OTPMK in its Key-RAM. From that point on you can run any software but you will not be able to decrypt any secret data which was encrypted with the OTPMK. On hardware which supports something like this, debugging hardware problems is easy and there is no danger of leaking any secret information. If something is useful/possible in any specific project obviously depends on the threat model and hardware capabilities. I knonw about the imx6 but that does not mean all the SoC unfortunatly. The other pb I see is this one where and do you plan to store the RO x509 the trusted one. if you use on OTP this means this is enough to ensure secured boot as if you can not modify the primary cert of key. No one can brake it. But as you load it in ram you need to be sure no one modify it. Even in unlock mode to do only allow to boot secure images by expected key. So you may not have secured place to store the cert or key in ram but only RAM. so we do need to forbidden this memory acces to everyone except the crypto API. if we want ot allow dev mode. the main problem is not console but env you need to drop RW env support and use only RO one, except for keyring support where you will a RW env but not executable and only accesable by crypto API otherwise you need to use a secured digest such as HMAC/CMAC/OMAC support to sign the env at runtime and ensure the symetric key is secured or encrypt it via aes (did this in the past) For an upcoming project we'll add HMAC support to the state storage Marc recently submitted. I've a patch too I need to send it For environment or state storage? envfs but I prefer to wait we have keystore support as this will store the key for the HMAC otherwise we need to use HW HMAC that store the key in the soc Another possibility is to use the HW AES key and a compiled in value to derive a per-device HMAC secret. The same approach can also be used in Linux for deriving the IMA/EVM HMAC secret. this for me need to be integrated in the keystore to be transparent for the rest of the API Best Regards, J. ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: ARM: UBI/UBIFS on spi-nor
I have a cortex-A9 based platform featuring a spi-nor (n25q256a).
Copying a bigger file (512KB) leads to a read failure
Has anybody used UBI/UBIFS on spi-nor successfully or seen a similar
issue?
Hello,
I've recently used UBI/UBIFS with a cortex-A7 based platform featuring a
spi-nor from Spansion (s25fl256). I had to introduce some changes for the
4-byte-mode, which will be set automatically, if barebox detects a flash
memory with more than 16MByte, because I was not able to reboot my
platform. But it seems that your problem is a different one.
I've just downloaded the datasheet of the n25q256a, and it seems that this
chip reports the JEDEC_MFR of ST (0x20), but needs the 4-byte CMD of
Macronix (0xb7).
This combination is currently not supported by barebox, but if you add an
additional 'case: CFI_MRF_ST' line to your 'set_4byte()' function, it
should hopefully work:
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 095a4ca..f54eb1f 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -157,6 +157,7 @@ static inline int set_4byte(struct m25p *flash, u32
jedec_id, int enable)
{
switch (JEDEC_MFR(jedec_id)) {
case CFI_MFR_MACRONIX:
+ case CFI_MFR_ST:
flash-command[0] = enable ? OPCODE_EN4B : OPCODE_EX4B;
return spi_write(flash-spi, flash-command, 1);
default:
Best regards,
Rolf
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
[PATCH 0/8 v2] prepare for rsa support
Hi, The following patch series prepare for the adding of the rsa digest support This will allow to verify a rsa signature of a file Introduction of a new command digest to handle the digest and check The next patch series will add RSA and keystore support v2: - rebase on next - add pbkdf2 to password/login framework - command allow to have runtime output used it in the new digest to print the supported algo The following changes since commit bbba2d05585637d04657dce293c0cb0611dbfeea: Merge branch 'for-next/state' into next (2015-03-13 08:32:38 +0100) are available in the git repository at: git://git.jcrosoft.org/barebox.git delivery/digest for you to fetch changes up to dbce6c62a5ff7585150fdb8b044580a96751577c: digest: allow algo to specify their length at runtime (2015-03-14 09:56:36 +0800) Jean-Christophe PLAGNIOL-VILLARD (8): digest: add verify callback command: rename digest.c to hashsum.c command: allow runtime usage command: add generic digest command digest: add digest callback crypto: add pbkdf2 hmac key generator password: add pbkdf2 support digest: allow algo to specify their length at runtime commands/Kconfig| 26 +- commands/Makefile | 3 +- commands/digest.c | 268 +++- commands/hashsum.c | 187 +++ commands/internal.h | 3 ++ common/Kconfig | 4 +++ common/command.c| 2 ++ common/password.c | 79 +--- crypto/Kconfig | 5 +++ crypto/Makefile | 2 ++ crypto/digest.c | 67 ++ crypto/hmac.c | 2 ++ crypto/internal.h | 4 +++ crypto/md5.c| 2 ++ crypto/pbkdf2.c | 94 crypto/sha1.c | 2 ++ crypto/sha2.c | 3 ++ crypto/sha4.c | 3 ++ include/command.h | 3 ++ include/crypto/pbkdf2.h | 23 include/digest.h| 25 +++-- 21 files changed, 610 insertions(+), 197 deletions(-) create mode 100644 commands/hashsum.c create mode 100644 commands/internal.h create mode 100644 crypto/pbkdf2.c create mode 100644 include/crypto/pbkdf2.h Best Regards, J. ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
[PATCH 8/8] digest: allow algo to specify their length at runtime
such as RSA as we load a DER key we will detect the key size
at runtime and so the algo length.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
include/digest.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/digest.h b/include/digest.h
index 8250ca7..41ad912 100644
--- a/include/digest.h
+++ b/include/digest.h
@@ -45,6 +45,7 @@ struct digest_algo {
struct digest {
struct digest_algo *algo;
void *ctx;
+ unsigned int length;
};
/*
@@ -100,7 +101,7 @@ static inline int digest_verify(struct digest *d, const
unsigned char *md)
static inline int digest_length(struct digest *d)
{
- return d-algo-length;
+ return d-length ? d-length : d-algo-length;
}
static inline int digest_set_key(struct digest *d, const unsigned char *key,
--
2.1.4
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
[PATCH 7/8] password: add pbkdf2 support
We will use barebox_password as salt and 1 round to generate a
64 bytes key.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
common/Kconfig| 4 +++
common/password.c | 79 +++
2 files changed, 55 insertions(+), 28 deletions(-)
diff --git a/common/Kconfig b/common/Kconfig
index 96ace6b..ad8a596 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -453,6 +453,10 @@ config PASSWD_SUM_SHA512
bool SHA512
select SHA512
+config PASSWD_CRYPTO_PBKDF2
+ bool PBKDF2
+ select CRYPTO_PBKDF2
+
endchoice
endif
diff --git a/common/password.c b/common/password.c
index 6ecf717..0e1db61 100644
--- a/common/password.c
+++ b/common/password.c
@@ -26,6 +26,7 @@
#include xfuncs.h
#include clock.h
#include generated/passwd.h
+#include crypto/pbkdf2.h
#if defined(CONFIG_PASSWD_SUM_MD5)
#define PASSWD_SUM md5
@@ -35,8 +36,14 @@
#define PASSWD_SUM sha256
#elif defined(CONFIG_PASSWD_SUM_SHA512)
#define PASSWD_SUM sha512
+#else
+#define PASSWD_SUM NULL
#endif
+#define PBKDF2_SALTbarebox_password
+#define PBKDF2_LENGTH 64
+#define PBKDF2_COUNT 1
+
int password(unsigned char *passwd, size_t length, int flags, int timeout)
{
unsigned char *buf = passwd;
@@ -277,45 +284,50 @@ EXPORT_SYMBOL(write_env_passwd);
static int __check_passwd(unsigned char* passwd, size_t length, int std)
{
- struct digest *d;
+ struct digest *d = NULL;
unsigned char *passwd1_sum;
unsigned char *passwd2_sum;
int ret = 0;
+ int hash_len;
- d = digest_alloc(PASSWD_SUM);
+ if (IS_ENABLED(CONFIG_PASSWD_CRYPTO_PBKDF2)) {
+ hash_len = PBKDF2_LENGTH;
+ } else {
+ d = digest_alloc(PASSWD_SUM);
- passwd1_sum = calloc(digest_length(d), sizeof(unsigned char));
+ hash_len = digest_length(d);
+ }
+ passwd1_sum = calloc(hash_len * 2, sizeof(unsigned char));
if (!passwd1_sum)
return -ENOMEM;
- passwd2_sum = calloc(digest_length(d), sizeof(unsigned char));
-
- if (!passwd2_sum) {
- ret = -ENOMEM;
- goto err1;
- }
+ passwd2_sum = passwd1_sum + hash_len;
- digest_init(d);
+ if (IS_ENABLED(CONFIG_PASSWD_CRYPTO_PBKDF2)) {
+ char *salt = PBKDF2_SALT;
- digest_update(d, passwd, length);
+ ret = pkcs5_pbkdf2_hmac_sha1(passwd, length, salt, strlen(salt),
+ PBKDF2_COUNT, hash_len, passwd1_sum);
+ } else {
+ ret = digest_digest(d, passwd, length, passwd1_sum);
+ }
- digest_final(d, passwd1_sum);
+ if (ret)
+ goto err;
if (std)
- ret = read_env_passwd(passwd2_sum, digest_length(d));
+ ret = read_env_passwd(passwd2_sum, hash_len);
else
- ret = read_default_passwd(passwd2_sum, digest_length(d));
+ ret = read_default_passwd(passwd2_sum, hash_len);
if (ret 0)
- goto err2;
+ goto err;
- if (strncmp(passwd1_sum, passwd2_sum, digest_length(d)) == 0)
+ if (strncmp(passwd1_sum, passwd2_sum, hash_len) == 0)
ret = 1;
-err2:
- free(passwd2_sum);
-err1:
+err:
free(passwd1_sum);
digest_free(d);
@@ -346,25 +358,36 @@ int check_passwd(unsigned char* passwd, size_t length)
int set_env_passwd(unsigned char* passwd, size_t length)
{
- struct digest *d;
+ struct digest *d = NULL;
unsigned char *passwd_sum;
- int ret;
+ int ret, hash_len;
- d = digest_alloc(PASSWD_SUM);
+ if (IS_ENABLED(CONFIG_PASSWD_CRYPTO_PBKDF2)) {
+ hash_len = PBKDF2_LENGTH;
+ } else {
+ d = digest_alloc(PASSWD_SUM);
- passwd_sum = calloc(digest_length(d), sizeof(unsigned char));
+ hash_len = digest_length(d);
+ }
+ passwd_sum = calloc(hash_len, sizeof(unsigned char));
if (!passwd_sum)
return -ENOMEM;
- digest_init(d);
+ if (IS_ENABLED(CONFIG_PASSWD_CRYPTO_PBKDF2)) {
+ char *salt = PBKDF2_SALT;
- digest_update(d, passwd, length);
-
- digest_final(d, passwd_sum);
+ ret = pkcs5_pbkdf2_hmac_sha1(passwd, length, salt, strlen(salt),
+ PBKDF2_COUNT, hash_len, passwd_sum);
+ } else {
+ ret = digest_digest(d, passwd, length, passwd_sum);
+ }
+ if (ret)
+ goto err;
- ret = write_env_passwd(passwd_sum, digest_length(d));
+ ret = write_env_passwd(passwd_sum, hash_len);
+err:
free(passwd_sum);
return ret;
--
2.1.4
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
[PATCH 2/8] command: rename digest.c to hashsum.c
as I'll add a new generic command named digest
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
commands/Kconfig | 14 +++---
commands/Makefile| 2 +-
commands/{digest.c = hashsum.c} | 0
3 files changed, 8 insertions(+), 8 deletions(-)
rename commands/{digest.c = hashsum.c} (100%)
diff --git a/commands/Kconfig b/commands/Kconfig
index 286e9ce..7e3e8b7 100644
--- a/commands/Kconfig
+++ b/commands/Kconfig
@@ -12,7 +12,7 @@ config HAS_POWEROFF
if COMMAND_SUPPORT
-config COMPILE_DIGEST
+config COMPILE_HASH
tristate
select DIGEST
help
@@ -917,7 +917,7 @@ config CMD_LS
config CMD_MD5SUM
tristate
- select COMPILE_DIGEST
+ select COMPILE_HASH
select MD5
prompt md5sum
help
@@ -982,7 +982,7 @@ config CMD_RMDIR
config CMD_SHA1SUM
tristate
- select COMPILE_DIGEST
+ select COMPILE_HASH
select SHA1
prompt sha1sum
help
@@ -994,7 +994,7 @@ config CMD_SHA1SUM
config CMD_SHA224SUM
tristate
- select COMPILE_DIGEST
+ select COMPILE_HASH
select SHA224
prompt sha224sum
help
@@ -1006,7 +1006,7 @@ config CMD_SHA224SUM
config CMD_SHA256SUM
tristate
- select COMPILE_DIGEST
+ select COMPILE_HASH
select SHA256
prompt sha256sum
help
@@ -1018,7 +1018,7 @@ config CMD_SHA256SUM
config CMD_SHA384SUM
tristate
- select COMPILE_DIGEST
+ select COMPILE_HASH
select SHA384
prompt sha384sum
help
@@ -1030,7 +1030,7 @@ config CMD_SHA384SUM
config CMD_SHA512SUM
tristate
- select COMPILE_DIGEST
+ select COMPILE_HASH
select SHA512
prompt sha512sum
help
diff --git a/commands/Makefile b/commands/Makefile
index 7344e01..e42662f 100644
--- a/commands/Makefile
+++ b/commands/Makefile
@@ -1,5 +1,5 @@
obj-$(CONFIG_STDDEV) += stddev.o
-obj-$(CONFIG_COMPILE_DIGEST) += digest.o
+obj-$(CONFIG_COMPILE_HASH) += hashsum.o
obj-$(CONFIG_COMPILE_MEMORY) += mem.o
obj-$(CONFIG_CMD_BOOTM)+= bootm.o
obj-$(CONFIG_CMD_UIMAGE) += uimage.o
diff --git a/commands/digest.c b/commands/hashsum.c
similarity index 100%
rename from commands/digest.c
rename to commands/hashsum.c
--
2.1.4
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
[PATCH 1/8] digest: add verify callback
this will allow to compare a md with the original one
When calling this do not call final
For RSA_SIGN verification final does not exist only verify
as final will be for signing
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
crypto/digest.c | 24 +++-
crypto/hmac.c | 1 +
crypto/internal.h | 2 ++
crypto/md5.c | 1 +
crypto/sha1.c | 1 +
crypto/sha2.c | 2 ++
crypto/sha4.c | 2 ++
include/digest.h | 6 ++
8 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/crypto/digest.c b/crypto/digest.c
index c06089d..52e8796 100644
--- a/crypto/digest.c
+++ b/crypto/digest.c
@@ -26,6 +26,8 @@
#include module.h
#include linux/err.h
+#include internal.h
+
static LIST_HEAD(digests);
static struct digest_algo *digest_algo_get_by_name(const char *name);
@@ -37,9 +39,29 @@ static int dummy_init(struct digest *d)
static void dummy_free(struct digest *d) {}
+int digest_generic_verify(struct digest *d, const unsigned char *md)
+{
+ int ret;
+ int len = digest_length(d);
+ unsigned char *tmp;
+
+ tmp = xmalloc(len);
+
+ ret = digest_final(d, tmp);
+ if (ret)
+ goto end;
+
+ ret = memcmp(md, tmp, len);
+ ret = ret ? -EINVAL : 0;
+end:
+ free(tmp);
+ return ret;
+}
+
int digest_algo_register(struct digest_algo *d)
{
- if (!d || !d-name || !d-update || !d-final || d-length 1)
+ if (!d || !d-name || !d-update || !d-final || !d-verify ||
+ d-length 1)
return -EINVAL;
if (!d-init)
diff --git a/crypto/hmac.c b/crypto/hmac.c
index 1462730..f39e4c8 100644
--- a/crypto/hmac.c
+++ b/crypto/hmac.c
@@ -136,6 +136,7 @@ struct digest_algo hmac_algo = {
.init = digest_hmac_init,
.update = digest_hmac_update,
.final = digest_hmac_final,
+ .verify = digest_generic_verify,
.set_key = digest_hmac_set_key,
.free = digest_hmac_free,
.ctx_length = sizeof(struct digest_hmac),
diff --git a/crypto/internal.h b/crypto/internal.h
index cc409d8..f482654 100644
--- a/crypto/internal.h
+++ b/crypto/internal.h
@@ -13,3 +13,5 @@ static inline int digest_hmac_register(struct digest_algo
*algo,
return 0;
}
#endif
+
+int digest_generic_verify(struct digest *d, const unsigned char *md);
diff --git a/crypto/md5.c b/crypto/md5.c
index fe17ff5..4847b38 100644
--- a/crypto/md5.c
+++ b/crypto/md5.c
@@ -294,6 +294,7 @@ static struct digest_algo md5 = {
.init = digest_md5_init,
.update = digest_md5_update,
.final = digest_md5_final,
+ .verify = digest_generic_verify,
.length = 16,
.ctx_length = sizeof(struct MD5Context),
};
diff --git a/crypto/sha1.c b/crypto/sha1.c
index a244b5d..09dee87 100644
--- a/crypto/sha1.c
+++ b/crypto/sha1.c
@@ -315,6 +315,7 @@ static struct digest_algo m = {
.init = digest_sha1_init,
.update = digest_sha1_update,
.final = digest_sha1_final,
+ .verify = digest_generic_verify,
.length = SHA1_SUM_LEN,
.ctx_length = sizeof(sha1_context),
};
diff --git a/crypto/sha2.c b/crypto/sha2.c
index cb89c82..9bf6541 100644
--- a/crypto/sha2.c
+++ b/crypto/sha2.c
@@ -304,6 +304,7 @@ static struct digest_algo m224 = {
.init = digest_sha224_init,
.update = digest_sha2_update,
.final = digest_sha2_final,
+ .verify = digest_generic_verify,
.length = SHA224_SUM_LEN,
.ctx_length = sizeof(sha2_context),
};
@@ -335,6 +336,7 @@ static struct digest_algo m256 = {
.init = digest_sha256_init,
.update = digest_sha2_update,
.final = digest_sha2_final,
+ .verify = digest_generic_verify,
.length = SHA256_SUM_LEN,
.ctx_length = sizeof(sha2_context),
};
diff --git a/crypto/sha4.c b/crypto/sha4.c
index 1c768e7..5c3097d 100644
--- a/crypto/sha4.c
+++ b/crypto/sha4.c
@@ -309,6 +309,7 @@ static struct digest_algo m384 = {
.init = digest_sha384_init,
.update = digest_sha4_update,
.final = digest_sha4_final,
+ .verify = digest_generic_verify,
.length = SHA384_SUM_LEN,
.ctx_length = sizeof(sha4_context),
};
@@ -341,6 +342,7 @@ static struct digest_algo m512 = {
.init = digest_sha512_init,
.update = digest_sha4_update,
.final = digest_sha4_final,
+ .verify = digest_generic_verify,
.length = SHA512_SUM_LEN,
.ctx_length = sizeof(sha4_context),
};
diff --git a/include/digest.h b/include/digest.h
index b890a7a..cba7814 100644
--- a/include/digest.h
+++ b/include/digest.h
@@ -32,6 +32,7 @@ struct digest_algo {
int (*update)(struct digest *d, const void *data, unsigned long len);
int (*final)(struct digest *d, unsigned char *md);
int (*set_key)(struct digest *d, const unsigned char *key, unsigned int
len);
+ int (*verify)(struct digest *d, const unsigned char *md);
unsigned int
[PATCH 4/8] command: add generic digest command
That can be used for digest calculation and verify
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
commands/Kconfig| 12 +++-
commands/Makefile | 1 +
commands/digest.c | 193
commands/hashsum.c | 68 --
commands/internal.h | 3 +
crypto/digest.c | 25 +--
include/digest.h| 8 ++-
7 files changed, 248 insertions(+), 62 deletions(-)
create mode 100644 commands/digest.c
create mode 100644 commands/internal.h
diff --git a/commands/Kconfig b/commands/Kconfig
index 7e3e8b7..847ff76 100644
--- a/commands/Kconfig
+++ b/commands/Kconfig
@@ -14,7 +14,7 @@ if COMMAND_SUPPORT
config COMPILE_HASH
tristate
- select DIGEST
+ select CMD_DIGEST
help
Turns on compilation of digest.c
@@ -842,6 +842,16 @@ config CMD_CMP
Returns successfully if the two files are the same, return with an
error if not
+config CMD_DIGEST
+ tristate
+ select DIGEST
+ prompt digest
+ help
+ Usage: digest -a algo [-k key | -K file] [-s sig | -S file]
FILE|AREA
+
+ Calculate a digest over a FILE or a memory area with the possibility
+ to checkit.
+
config CMD_DIRNAME
tristate
prompt dirname
diff --git a/commands/Makefile b/commands/Makefile
index e42662f..b902f58 100644
--- a/commands/Makefile
+++ b/commands/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_STDDEV) += stddev.o
+obj-$(CONFIG_CMD_DIGEST) += digest.o
obj-$(CONFIG_COMPILE_HASH) += hashsum.o
obj-$(CONFIG_COMPILE_MEMORY) += mem.o
obj-$(CONFIG_CMD_BOOTM)+= bootm.o
diff --git a/commands/digest.c b/commands/digest.c
new file mode 100644
index 000..fee4643
--- /dev/null
+++ b/commands/digest.c
@@ -0,0 +1,193 @@
+/*
+ * Copyright (c) 2015 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
+ *
+ * GPLv2 ONLY
+ */
+
+#include common.h
+#include command.h
+#include fs.h
+#include fcntl.h
+#include errno.h
+#include xfuncs.h
+#include malloc.h
+#include digest.h
+#include getopt.h
+#include libfile.h
+
+#include internal.h
+
+int __do_digest(struct digest *d, unsigned char *key, int keylen,
+ unsigned char *sig,
+ int argc, char *argv[])
+{
+ int ret = 0;
+ int i;
+ unsigned char *hash;
+
+ if (argc 1)
+ return COMMAND_ERROR_USAGE;
+
+ hash = calloc(digest_length(d), sizeof(unsigned char));
+ if (!hash) {
+ perror(calloc);
+ return COMMAND_ERROR_USAGE;
+ }
+
+ while (*argv) {
+ char *filename = /dev/mem;
+ loff_t start = 0, size = ~0;
+
+ /* arguments are either file, file+area or area */
+ if (parse_area_spec(*argv, start, size)) {
+ filename = *argv;
+ if (argv[1] !parse_area_spec(argv[1], start, size))
+ argv++;
+ }
+
+ ret = digest_file_window(d, filename,
+key, keylen,
+hash, sig, start, size);
+ if (ret 0) {
+ ret = 1;
+ } else {
+ if (!sig) {
+ for (i = 0; i digest_length(d); i++)
+ printf(%02x, hash[i]);
+
+ printf( %s\t0x%08llx ... 0x%08llx\n,
+ filename, start, start + size);
+ }
+ }
+
+ argv++;
+ }
+
+ free(hash);
+ digest_free(d);
+
+ return ret;
+}
+
+static void prints_algo_help(void)
+{
+ puts(\navailable algo:\n);
+ digest_algo_prints(\t);
+}
+
+static int do_digest(int argc, char *argv[])
+{
+ struct digest *d;
+ unsigned char *tmp_key = NULL;
+ unsigned char *tmp_sig = NULL;
+ char *sig = NULL;
+ char *sigfile = NULL;
+ size_t siglen = 0;
+ char *key = NULL;
+ char *keyfile = NULL;
+ size_t keylen = 0;
+ size_t digestlen = 0;
+ char *algo = NULL;
+ int opt, ret;
+
+ if (argc 2)
+ return COMMAND_ERROR_USAGE;
+
+ while((opt = getopt(argc, argv, a:k:K:s:S:)) 0) {
+ switch(opt) {
+ case 'k':
+ key = optarg;
+ keylen = strlen(key);
+ break;
+ case 'K':
+ keyfile = optarg;
+ break;
+ case 'a':
+ algo = optarg;
+ break;
+ case 's':
+ sig = optarg;
+ siglen = strlen(sig);
+ break;
+ case 'S':
+ sigfile = optarg;
+
[PATCH 3/8] command: allow runtime usage
This will allow as example to list the currently supported digest.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
common/command.c | 2 ++
include/command.h | 3 +++
2 files changed, 5 insertions(+)
diff --git a/common/command.c b/common/command.c
index 61191c2..dc2cb88 100644
--- a/common/command.c
+++ b/common/command.c
@@ -47,6 +47,8 @@ void barebox_cmd_usage(struct command *cmdtp)
puts(cmdtp-help);
putchar('\n');
}
+ if (cmdtp-usage)
+ cmdtp-usage();
#endif
}
EXPORT_SYMBOL(barebox_cmd_usage);
diff --git a/include/command.h b/include/command.h
index 5d5bf53..3aca1a9 100644
--- a/include/command.h
+++ b/include/command.h
@@ -54,6 +54,7 @@ struct command {
uint32_tgroup;
#ifdef CONFIG_LONGHELP
const char *help; /* Help message(long) */
+ void(*usage)(void);
#endif
}
#ifdef __x86_64__
@@ -115,8 +116,10 @@ static const __maybe_unused char cmd_##_name##_help[] =
#ifdef CONFIG_LONGHELP
#define BAREBOX_CMD_HELP(text) .help = text,
+#define BAREBOX_CMD_USAGE(fn) .usage = fn,
#else
#define BAREBOX_CMD_HELP(text)
+#define BAREBOX_CMD_USAGE(fn)
#endif
#define BAREBOX_CMD_GROUP(grp) .group = grp,
--
2.1.4
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
