diracdeltas / code-integrity-everywhere Goto Github PK

At some point, we should write up a document explaining the general problem(s) we want to solve with Code Integrity Everywhere, as well as the specific problem(s) we want to solve for SecureDrop/GlobaLeaks.

Somewhat related to #6, we should ideally discuss and agree on a file format before we begin to implement a parsing algorithm for it. An example file format was mentioned here: https://securedrop.hackpad.com/Manifest-qDYxsCQhchp

Somewhat specified in https://securedrop.hackpad.com/Manifest-qDYxsCQhchp.

We currently have https://securedrop.hackpad.com/Code-integrity-everywhere-with-TLD-uLKsXCe9rUc, but we should clean it up and push it to GitHub as a specification for Code Integrity Everywhere with TLD.

Perhaps worth looking at Tor Browser's implemention of the .onion handler for reference.

The built-in interface for signature verification in Firefox extensions only supports RSA keys and has a very obscure signature format. https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIDataSignatureVerifier

Pros:

• Implemented directly in C++, so it's not javascript crypto
• Firefox uses it internally for verifying updates to all extensions (maybe also to Firefox itself?), so it is reasonably well-tested.

Cons:

• Doesn't use a common signature format like GPG; basically need to use nss-tools to generate the signature.
• No support for elliptic curves. (What are the benefits of EC signatures in this case?)

@hellais started working on this today using a toolbar frame as described here: https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/ui#Toolbar.

We couldn't get the javascript inside the frame to run.

My starting proposal is to have the "hard-fail" page (which the user is directed to as soon as any resource fails code integrity verification) look similar to the new Chrome malware/phishing page:

Instead of "Phishing attack ahead", it could say, "The site ahead cannot be verified."