Hello, Nelson.
Thank you for detailed answer.
I am very curious about:
FIPS 140 will not allow *any* hardware pure noise source to be used by itself
as a random number/bit source. Instead, such a source MUST be fed into a DRBG
from which any internal random data is taken.
The statement above provokes another question.
Let assume, I have high-quality, conformant to all relevant standards (e.g. FIPS 140-1),
hardware, true random numbers source - token "B". Token vendor intimately cares
about standard API to the token, and provides PKCS#11 library.
Indeed, there are very good commercial true RNG, and the only API to them we
can rely is PKCS#11.
Let's look at some Mozilla product, say, Thunderbird or Firefox. I can open "Security Device
Manager" then add token "B" into the modules list. But, this will only result in
seeding softoken's RNG once upon application start.
It is obvious, that hardware RNG is more secure than softoken's builtin one. Is
it achievable to make softoken use hardware RNG all the time, being or not
being FIPS-compatible ?
Maybe chaining two FIPS-compliant devices will result in FIPS-compliant
aggregate device ?
Application --(sign_req)--> Mozilla softoken --(C_GenerateRandom)-->
hardware RNG
Best regards,
--
Konstantin Andreev.
On 07/18/10 03:13, Nelson B Bolyard wrote:
On 2010-07-12 02:18 PDT, Konstantin Andreev wrote:
Hello.
I am asking in this newsgroup, because I believe FIPS mode can affect the
answer.
Let assume
-- Token A is software token, and able to make ECC signatures.
-- Token B is hardware token providing TRUE random numbers.
Certainly, I'd like the token B be used as random number source as much as
possible.
Would it be correct if application takes random number from token B, and passes
to token A to be used as ECC signature nonce ?
No, but it would be correct to use random data from token B as "additional
input" to feed into token A's PRNG/DRBG, from which the ECC signature nonce will be
derived. If both Tokens are FIPS compliant, that would be fine.
Is it compatible with FIPS mode requirements ?
Let's forget for a while that PKCS#11 doesn't provide a way to application to
pass an own random to ECC signature mechanism.
Having the application directly provide the ECC signature nonce will not be FIPS 140
compliant AFAIK. The FIPS 140-1 token must have its own DRBG, and that DRBG must get its
own seed from somewhere. It cannot rely on the application to provide that seed, but it
can accept "additional input" as input to the DRBG.
(DRBG is the new buzz word for PRNG, the difference being that DRBGs generate bit streams whereas
PRNGs generate numbers, by definition. DRBG means "Deterministic Random Bit Generator".
Some think this is an oxymoron. In the context of DRBGs, the term "Additional Input" is a
term of art. See section 8.7.2, page 21, of SP 800-90.)
FIPS 140 will not allow *any* hardware pure noise source to be used by itself
as a random number/bit source. Instead, such a source MUST be fed into a DRBG
from which any internal random data is taken.
Read all about the requirements for DRBGs in
NIST Special Publication 800-90
Recommendation for Random Number Generation Using
Deterministic Random Bit Generators
revised March 2007
http://csrc.nist.gov/publications/nistpubs/800-90/SP800-90revised_March2007.pdf
Regards,
/Nelson Bolyard
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
