Skip to content

Instantly share code, notes, and snippets.

@saulshanabrook
Created October 19, 2016 14:20
Show Gist options
  • Star 55 You must be signed in to star a gist
  • Fork 5 You must be signed in to fork a gist
  • Save saulshanabrook/b74984677bccd08b028b30d9968623f5 to your computer and use it in GitHub Desktop.
Save saulshanabrook/b74984677bccd08b028b30d9968623f5 to your computer and use it in GitHub Desktop.
Saving Web Crypto Keys using indexedDB

This is a working example on how to store CryptoKeys locally in your browser. We are able to save the objects, without serializing them. This means we can keep them not exportable (which might be more secure?? not sure what attack vectors this prevents).

To try out this example, first make sure you are in a browser that has support for async...await and indexedDB (latest chrome canary with chrome://flags "Enable Experimental Javascript" works). Load some page and copy and paste this code into the console. Then call encryptDataSaveKey(). This will create a private/public key pair and encrypted some random data with the private key. Then save both of them. Now reload the page, copy in the code, and run loadKeyDecryptData(). It will load the keys and encrypted data and decrypt it. You should see the same data logged both times.

async function encryptDataSaveKey() {
var data = await makeData();
console.log("generated data", data);
var keys = await makeKeys()
var encrypted = await encrypt(data, keys);
callOnStore(function (store) {
store.put({id: 1, keys: keys, encrypted: encrypted});
})
}
function loadKeyDecryptData() {
callOnStore(function (store) {
var getData = store.get(1);
getData.onsuccess = async function() {
var keys = getData.result.keys;
var encrypted = getData.result.encrypted;
var data = await decrypt(encrypted, keys);
console.log("decrypted data", data);
};
})
}
function callOnStore(fn_) {
// This works on all devices/browsers, and uses IndexedDBShim as a final fallback
var indexedDB = window.indexedDB || window.mozIndexedDB || window.webkitIndexedDB || window.msIndexedDB || window.shimIndexedDB;
// Open (or create) the database
var open = indexedDB.open("MyDatabase", 1);
// Create the schema
open.onupgradeneeded = function() {
var db = open.result;
var store = db.createObjectStore("MyObjectStore", {keyPath: "id"});
};
open.onsuccess = function() {
// Start a new transaction
var db = open.result;
var tx = db.transaction("MyObjectStore", "readwrite");
var store = tx.objectStore("MyObjectStore");
fn_(store)
// Close the db when the transaction is done
tx.oncomplete = function() {
db.close();
};
}
}
async function encryptDecrypt() {
var data = await makeData();
console.log("generated data", data);
var keys = await makeKeys()
var encrypted = await encrypt(data, keys);
console.log("encrypted", encrypted);
var finalData = await decrypt(encrypted, keys);
console.log("decrypted data", data);
}
function makeData() {
return window.crypto.getRandomValues(new Uint8Array(16))
}
function makeKeys() {
return window.crypto.subtle.generateKey(
{
name: "RSA-OAEP",
modulusLength: 2048, //can be 1024, 2048, or 4096
publicExponent: new Uint8Array([0x01, 0x00, 0x01]),
hash: {name: "SHA-256"}, //can be "SHA-1", "SHA-256", "SHA-384", or "SHA-512"
},
false, //whether the key is extractable (i.e. can be used in exportKey)
["encrypt", "decrypt"] //must be ["encrypt", "decrypt"] or ["wrapKey", "unwrapKey"]
)
}
function encrypt(data, keys) {
return window.crypto.subtle.encrypt(
{
name: "RSA-OAEP",
//label: Uint8Array([...]) //optional
},
keys.publicKey, //from generateKey or importKey above
data //ArrayBuffer of data you want to encrypt
)
}
async function decrypt(data, keys) {
return new Uint8Array(await window.crypto.subtle.decrypt(
{
name: "RSA-OAEP",
//label: Uint8Array([...]) //optional
},
keys.privateKey, //from generateKey or importKey above
data //ArrayBuffer of the data
));
}
@icedevml
Copy link

Such possibility with exportable = false is very interesting, it allows to generate a key pair in the browser and permanently store it in such a way, that no malicious JavaScript code (XSS or some JavaScript on the server itself) would be able to steal it. An authentication scheme which involves asymmetric cryptography has some very nice properties in terms of security - the server remembers only public keys (even if somebody would manage to steal them - users are secure) and the user's private key could be stolen only by means of malware which has a direct access to the user's browser.

@EGreg
Copy link

EGreg commented Nov 30, 2017

Did you guys find any downsides to this? The keys are stored in the IndexedDB, but perhaps they are serialized and stored openly. Who has access to IndexedDB? Have you found out any possible attacks?

It seems to me that deriving a key from the user's fingerprint or password, and using it to wrap or encrypt all the other keys, increases the security. What are your thoughts about that? Like TrueCrypt did with the disk volumes.

Fingerprint -> Master key -> Various encrypted private keys or wrapped symmetric keys that can be saved / transmitted.

That means, to use the app, the user would have to decrypt the Master Key using their fingerprint or password. And the Master key would itself be stored encrypted in the db.

The reason for the Fingerprint itself not being the Master Key is so the user can change their password by having only the Master Key be re-encrypted and saved with the new encryption without having to re-encrypt all the other keys.

@kavinRkz
Copy link

kavinRkz commented May 18, 2018

Web Crypto does not seem to generate a simple AES Private/Public Key pair that enables me to encrypt/decrypt, as is the case with RSA-OAEP for example, where I can generate a public/private key pair.Is it possible to achieve my scenario with AES? If so, how should this be done?

@themikefuller
Copy link

@EGreg

This is something I've been looking into as well and I can't find a clear answer.

We can store imported and generated cryptoKeys in memory or IndexedDB as cryptoKeys for quick operations. They aren't strings, or plain objects, or json objects. They cannot be extracted directly, only used for their intended operations. So it seems.

That leads me to think they might be stored as one-way functions. Essentially its just a function, and its constructed using values that when combined can derive the same "state" that your cryptoKey has when its in memory. The parts themselves however cannot be used to derive the initial material (raw bits).

This might be ok. I'd really like to see some documentation somewhere that outlines how they are TRUELY stored on disk when stored in IndexedDB. A "safe" non-extractable cryptoKey stored in IndexedDB that can be used to quickly encrypt or derive our true key sounds REALLY good. From a security stand point, sounds too good to be true.

If someone has a link that can demonstrate that the imported CryptoKey CANNOT be extracted (i.e. the raw bits can't be derieved from the hard drive) I'd like to see that. If its merely the case that they are encrypted because its ASSUMED that the file system is encrypted when not in use, that isn't good enough for me. I'd rather do it the hard way then find out later that cryptoKeys have been stored with the raw bits in plain text in some browser cache file somewhere the whole time.

@kavinRkz

If you're new to the Web Crypto API (crypto.subtle) it can be very confusing and there isn't a silverbullet framework out there that I've seen just yet. Personally, I've been using it every day for a while now and actually I like it a lot now. It grows on you. I don't think I want a framework, but I have been writing my own abstractions and functions around the API for ease of use.

To help you learn I recommend this above all other resources:
https://github.com/diafygi/webcrypto-examples

Also, to help get you started, I am writing some examples using various parts of the API. I have an example for AES here:
https://github.com/themikefuller/Web-Cryptography

Look for "AES-GCM encryption / decryption with PBKDF2 key derivation". There are some examples, and I included an aes.js file that has the function that is outlined in the readme.

AES is symmetric encryption. The key used to encrypt is the key used to decrypt. The "password" you use when encrypting with AES is usually used in another function to derive the necessary bits required to encrypt (128 or 256). Many libraries provide this, along with encoding and iv / salt generation, in their encrypt / decrypt functions. Web Crypto is closer to metal. You are using encryption primitives and dealing with byteArrays.

Public and private keys are a part of asymmetric encryption and the Web Crypto API supports RSA and ECDH. On that note, you can also use RSA or ESDSA to sign and verify messages, but to just encrypt between two separate parties, you want to use ECDH. I also provide an example for that under the cheeky heading "Formula for encrypted communication with advanced extraterrestrial lifeforms (Aliens) familar with Elliptic Curve Diffie-Hellman and JavaScript".

If you ever need help with this, let me know.

@EGreg
Copy link

EGreg commented Oct 31, 2019

@themikefuller have you ever found out?

It seems to me that encrypting and then later decrypting a non-extractable key leaves you with an extractable key. I haven't seen a way to keep a key non-extractable in the JS environment even after it's been encrypted and then later decrypted. I wish it was something that was stored behind the scenes in the actual JS object to be encrypted/decrypted. Did you find out anything along these lines? Then we don't have to rely on filesystem encryption.

@tcortega
Copy link

tcortega commented Nov 5, 2021

@themikefuller have you ever found out?

It seems to me that encrypting and then later decrypting a non-extractable key leaves you with an extractable key. I haven't seen a way to keep a key non-extractable in the JS environment even after it's been encrypted and then later decrypted. I wish it was something that was stored behind the scenes in the actual JS object to be encrypted/decrypted. Did you find out anything along these lines? Then we don't have to rely on filesystem encryption.

Have you ever found out?

@themikefuller
Copy link

@tcortega

I'm sorry, I am no longer following this thread. I barely recall what the discussion involved at this point. Hold on... Let me re-read...

I'm going to try to answer to the best of my knowledge at this point:

If the key is stored (as a cryptoKey object) in IndexedDB, and was not initiated as "extractable" then it cannot be saved out from the browser. HOWEVER... That doesn't mean that the browser's data could not be copied out and compromised. If it can be accessed then the data lives somewhere. It isn't magically. Again, it might not be able to be "extracted" via a browser API, but if the data persists, then it exists somewhere on the hard drive and could be duplicated and extracted by some other means.

Since this discussion thread's emergence, if I require keys to be securely stored, I have taken to extracting the keys and encrypting them myself before storing them (whether in indexedDB as an encrypted string or elsewhere).

That's all I know and likely all I'll ever know.

@tcortega
Copy link

tcortega commented Nov 5, 2021 via email

@dscaravaggi
Copy link

I'm interested in this thread and I tried to understand if chromium has already included TPM2 by heart, I found some git commit about it but I'm not able to understand is is rolled up in officials builds.
on the other hand should I trust webcrytpt in android >10 webview ?

@Vishwas1
Copy link

Is there any paper on security of cryptoKey storage?

@tcortega
Copy link

@Vishwas1 The way I was successfull in extracting non-extractable keys was simply via http request interception and modifying the js that generated the key in the first place. This should be possible in literally any application. Although it may not be as easy as it was for me.

@erdum
Copy link

erdum commented Sep 28, 2023

@tcortega how would you rate its security on a scale of 1 to 10?

@tcortega
Copy link

@tcortega how would you rate its security on a scale of 1 to 10?

I'd rate it 4 out of 10 haha, but what's up with this question out of nowhere?

@erdum
Copy link

erdum commented Sep 28, 2023

I am going to use it for a web-based end-to-end encrypted messaging system.
For that purpose, I think it's pretty safe because the only vulnerability comes from the user end if the user gives his device to some malicious person then he might steal his private key otherwise there is no way to use networking to grab the private key.

Some sort of the same mechanism might Whatsapp using because when you uninstalled it all of your chats are gone unless you have a backup so a similar thing will happen to my messaging system.

If he cleared his browser data then all the previous ciphers will also be gone and I don't need to save the cipher on the database because they can only be decrypted with the user's private key so as long as the user has his private key he can read those cipher so private key and cipher associated with that key will reside on user IndexDB.

What would you say? @tcortega

@themikefuller
Copy link

@erdum I built a web-based end-to-end encrypted messaging app using this. The user generates their keypair and then backs up their private key (it gets password encrypted first) to file. It has worked well. Is it perfect? No. Do you have to trust the website isn't uploading the user's private key when they generate it? Yes.

Obviously, I trust my own system. It is as safe as the user's browser is though.

@erdum
Copy link

erdum commented Sep 28, 2023

@themikefuller yup buddy I have same idea, just don't know how to password encrypt private-key?

@themikefuller
Copy link

@erdum

I built a library around using crypto.subtle in the browser.
https://github.com/StarbaseAlpha/Cryptic

I don't expect you to use it or do everything the way I did, but you might gain some insights from it. I'll include some code below that uses functions from that library. You can copy / paste it into your browser console to get an idea:
https://gist.github.com/themikefuller/d4fbfbd11dfd41f32df04fa07002703e

@erdum
Copy link

erdum commented Sep 28, 2023

@themikefuller thanks buddy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment