Friday, June 13, 2014

Week 5

The chrome extension performs basic AES decryption now. The data are in three different encoding formats:

  • Base64, for retrieving from the server
  • Byte arrays, for decryption
  • Text string, for displaying

We adopt the AES algorithm in CBC mode for decryption and encryption. The following is the data retrieved from the server:

Since we do not have mechanism for key distribution now, the decryption key is included in the data, the shorter base64 string. The key length indicates that the encryption algorithm is AES128. Also, the initialization vector (iv) for CBC decryption is included in the ciphertext, the longer base64 string, as the first 16 bytes. Knowing the key and the iv, we can obtain the plaintext by decryption.
The plaintext includes the message, "Hello Secret world!" and the corresponding signature in RSA scheme.

I also managed to come up with a way for key management and storage on the client side. Because it is generally considered not possible to use file systems on the browser-side in JavaScript (see http://stackoverflow.com/questions/585234/how-to-read-and-write-into-file-using-javascript), I have to use the not-so-secure chrome.storage API.

To ensure security, the following is a preliminary idea to encrypt the keys stored on the extension. Every user creates a user name and the associated password. All the keys are stored encrypted using AES with the hash value of the password as the key. To verify the user, another pair of plaintext and ciphertext is stored with the plaintext randomly generated. Thus, only the encrypted keys and a pair of plaintext and cipher text are stored. In order to check whether a user enters the correct password, we only have to take the hash value of the input, use it as the key to decrypt the ciphertext, and check whether the resulted plaintext matches the one stored on the extension.

For next week, I will try to do more research on this problem: how to store keys securely with storage that the attackers may have access to. Also, I will implement the idea above or some other solutions to solve the problem.

2 comments:

  1. Chrome (as well as firefox/mozilla) have been using NSS to store/use certificates.

    http://code.google.com/p/chromium/wiki/LinuxCertManagement

    https://groups.google.com/forum/#!topic/mozilla.dev.tech.crypto/4F3z644W8BM

    https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53pQgNR-DppMYwt9XvE6s/edit?pli=1

    http://code.google.com/p/chromium/wiki/LinuxCertManagement

    https://groups.google.com/forum/#!topic/mozilla.dev.tech.crypto/4F3z644W8BM

    https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_API_Guidelines

    user can import their certificate using chrome's gui interface for certs. or i think nss-tools can be used as well. chrome browser is statically linked with the nss library i believe. nss api has a s/mime component. we might want to use that.... if not that then there is an api to interact with the certdb.

    ReplyDelete