2

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?

Markus A.
  • 201
  • 2
  • 5

2 Answers2

6

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

Community
  • 1
poncho
  • 147,019
  • 11
  • 229
  • 360
  • 1
    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? – Markus A. Apr 20 '18 at 04:43
  • @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). – Gilles 'SO- stop being evil' Apr 20 '18 at 06:36
  • @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? – Markus A. Apr 20 '18 at 13:44
  • 1
    @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? :) – Markus A. Apr 20 '18 at 14:17
  • @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). – Gilles 'SO- stop being evil' Apr 21 '18 at 08:39
  • @Gilles Hmmm... If I understand correctly, Bouncy Castle doesn't use any native bindings. Also, their FIPS documentation states: "Zeroization of key material is managed via the JVM's garbage collection process. Proactive zeroization on de-allocation by finalisers is also used where appropriate as zeroization on de-allocation is a FIPS 140-2 requirement.". From that, it sounds like garbage collection isn't in principle a problem, at least not in Java. After doing some research, it also doesn't seem like it's possible in Java to prevent any memory from being paged out to disk... – Markus A. Apr 21 '18 at 14:29
  • @MarkusA. GC isn't necessarily a problem, it depends how it's implemented. It's only a problem if it can move objects around without zeroizing the old copy. C's realloc has the same problem. If you have key material in a GC'ed object, you need to ensure that the GC doesn't do copying (which isn't necessarily the case in JavaScript since it's implementation-dependent), and you need to trigger a collection at every point where zeroizing is necessary. – Gilles 'SO- stop being evil' Apr 21 '18 at 16:04
3

  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.

e-sushi
  • 17,891
  • 12
  • 83
  • 229