2
$\begingroup$

I'm working on a system that needs to use cryptographic functions that must be FIPS 140-2, Level 1 validated. The challenging part is that some of this system needs to run in the browser. For maintainability reasons and ease of use, I would really like to avoid having to resort to applets or browser plugins or Active-X controls or something of that sort, and would much rather build this part of the system in JavaScript.

So, I've been searching for validated JavaScript modules, but this website:

https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Validated-Modules/Search

which lists all (?) currently validated modules if you click on "Show All", does not give me much hope to find one.

So, here's what I'm thinking:

Can I take one of the Java modules (like Bouncy Castle) and cross-compile them to JavaScript using something like GWT?

Or can I take one of the C or C++ modules and compile it into asm.js?

Or, to ask the question even more generally: How does (cross-)compilation or translation of validated code affect the validation?

Improve this question
$\endgroup$
0

2 Answers 2

Reset to default
6
$\begingroup$

I wouldn't give much hope in finding a native Javascript crypto implementation that's FIPS certified. The reason is zeroization; FIPS is particular about knowing when CSPs [1] are zeroized; Javascript does garbage collection, which means that you're never quite sure when things are zeroized.

And, if by cross-compiling, you mean taking a certified implementation, and automatically converting it into Javascript, well, you won't solve the problem.

Sorry, but I wish I had better news for you.

[1]: Critical Security Parameters; essentially FIPS terminology for keys

Improve this answer
$\endgroup$
7
  • 1
    $\begingroup$ Shouldn't Java be suffering from the same problem, since it's also garbage collected? Somehow Bouncy Castle and several other Java libraries have manage to get certified. Wouldn't it be enough to just store all CSPs in arrays and overwrite them with zeroes before you release the reference to the array for it to eventually get garbage collected? $\endgroup$
    – Markus A.
    Commented Apr 20, 2018 at 4:43
  • $\begingroup$ @MarkusA. That depends how memory management works. Your strategy is ok if objects are never moved during their lifetime and you have enough control over when everything is deallocated, including temporary copies made by auxiliary functions made by the implementation. You can't do this in a runtime that includes a garbage collector that works by coping (unless the GC itself zeroizes the old copy of the data, which would be atypical). $\endgroup$
    – Gilles 'SO- stop being evil'
    Commented Apr 20, 2018 at 6:36
  • $\begingroup$ @Gilles The "moving" and "temporary copies" points make perfect sense. Thank you. But shouldn't these apply to Java just as much as to JavaScript? $\endgroup$
    – Markus A.
    Commented Apr 20, 2018 at 13:44
  • 1
    $\begingroup$ @Gilles Come to think of it: Given that most modern operating systems support swap files and could page out relevant memory to disk at any moment to basically create a permanent copy, how can ANY algorithms running on such an operating system ever truly fulfill the zeroization requirements? :) $\endgroup$
    – Markus A.
    Commented Apr 20, 2018 at 14:17
  • $\begingroup$ @MarkusA. Indeed this applied to Java as well. In Java you can get away with it through native bindings which give you precise control over memory management. There's no such thing in JavaScript. Regarding swap, you either don't have it (mobile devices), turn it off (servers), disable its usage for cryptographic materials (I know at least gpg does it if it has the right capability), or I think FIPS 140 level 1 lets you get away with encrypting the swap (even though the data does remain accessible as long as the machine isn't rebooted). $\endgroup$
    – Gilles 'SO- stop being evil'
    Commented Apr 21, 2018 at 8:39
3
$\begingroup$

  1. You can convert/cross-compile the code, but that won’t port over any validation or even certification. In the end, a cross-compiled product is a new product – requiring revalidation. Unless such (re)validation happens, any cross-compilation results have to be treated as “unvalidated cryptography”.

    Unvalidated cryptography is viewed by NIST as providing no protection to the information or data—in effect the data would be considered unprotected plaintext. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2 is applicable. In essence, if cryptography is required, then it must be validated.

  2. Javascript itself has several problems when it comes to cryptography, which is why Window.crypto API was born. That API hooks into non-javascript crypto functionalities provided via the web browser client program itself. Yet, as far as I’m aware, that API has not been validated; among other reasons, due to it’s somewhat immature status. So, from a validation point of view, that too has to be treated as offering “no protection”.

  3. Now, related to your

    … FIPS 140-2, Level 1 validated. The challenging part is that some of this system needs to run in the browser…

    At the time of writing this, there is no “browser only” way to do this. Yet, if you add a server to the equation, you can let the validated crypto be handled by that server – which would be the most recommendable anyway since you can control a server, but you can’t control a client.

    As an aside: I don’t see the US Government jumping at Javascript-based cryptographic modules for it’s sensitive information anytime soon – which is why you shouldn’t put much hopes in discovering a validated Javascript module in the near future… if at all.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.