By Mike Olsen, CEO
To ensure Proctorio stays ahead of the latest security threats, we are updating our security platform with a variety of enhancements:
- We have hardened the key derivation method used to generate the Zero-Knowledge Encryption encryption keys. Moving forward, we increased the number of math operations used to generate keys by 9,900%. We are doing this to reduce the chances of a brute force attack as computing power continues to improve.
- Moving forward, all new recordings will be encrypted with native WebCrypto package built into the browser. These updates have been live for a month and show no signs of performance problems.
- We’ve added a High Security Plus option that provides symmetric key encryption with an asymmetric RSA public key, generated by the institution.
Existing customers will have the option to apply these features to their institutions at no cost.
For additional information, please contact your Proctorio representative or contact us at https://proctorio.com/signup to get started with Proctorio.
Why are we making these updates now?
When we started working on Proctorio in 2013, we began development on Chrome 27. Gangnam Style had just come out, and everyone was watching it on their brand new iPhone 5. In other words, it was a different time.
One of our earliest goals with Proctorio was to create an online proctoring service that placed test-taker privacy and security at the center, but was able to maintain a lightweight deployment of the software. As a result, we created Proctorio as a browser extension that didn’t have to be installed natively onto a test taker’s computer. One of the most powerful elements to easily add encryption to test taker data was, and continues to be, cryptography.
After extensive evaluation, we integrated SJCL from Stanford to add cryptography to those first versions of Proctorio. As much as we wished Chrome supported native cryptography back then, it would take another 10 versions to see the first signs of WebCrypto, a basic cryptography function brought to the browser.
In the unfortunate event the user’s machine has been compromised with a malware program, cache timing attacks are the least of the users’ concerns, since any malware would likely be able to extract key/password information directly from memory. However, since WebCrypto has proven to be many times faster and is built into the browser platform, in our update as of release 1.4.20276.1, we have replaced all-new recordings with native WebCrypto instead of SJCL.
Next, in order to secure the exam recordings, we use information from the test administering platform. Each exam uses a unique combination of this information, effectively generating unique keys for every user’s recorded exam attempt. We then use symmetric cryptography to encrypt the data using AES-128. Since we can’t control the complexity of this information, we use a key derivation function to reduce the potential of brute force attacks. We originally chose PBKDF2-HMAC-SHA1 for this task.
The RFC written in 2000 for PBKDF2 recommended an iteration count of 1,000 rounds. However, by 2013, when we implemented it at Proctorio, password managers were already using 10,000 iterations. We decided to go with 12,000 iterations in our implementation. But now, in 2020, as computers and GPUs have become faster, it is time to further reduce the possibility of brute force vulnerabilities.
In version 1.4.20276.1, we switched out SHA1 with SHA512, implementing PBKDF2-HMAC-SHA512. To even further slow down key generation, we increased the iteration count from 12,000 to 1,200,000. Finally, in addition to this change, we decided to move from AES-128 to AES-256. This change will guard against multi-target attacks as well as a post-quantum world.
Lastly, in version 1.4.20311.1 we have launched an option to move to asymmetrical keys, generated and managed by the partnered institution. Any institution can enroll in this program but it requires the institution to generate the public key and save the private key. Public keys and options are provided to Proctorio via an account manager.
Private keys must be distributed to any end-user who needs gradebook access.
We built this option for three reasons:
- The unshared information for derived keys can have very little entropy. This is true in Learning Management Systems like Canvas or Moodle, which use zero-based sequential identifiers.
- It protects the security of the exam recording data from potential third-party access. Again, in the case of Canvas or Moodle, these systems are commonly hosted by a third party. Since this third party has access to the keys they can decrypt the data.
- Most test platforms have admin or elevated roles that allow unrestricted access. In these cases, it may be difficult to control access to the recordings while allowing these users to perform their normal duties. Using the organization’s own control over the private key will allow them to control access at a finer level.
In future versions, we plan to allow an individual institution-approved representative to generate and use their own asymmetric public key.
We continue to work hard to protect our partners and test takers against the latest threats, and with this update, we are excited to provide administrators with even more control and options to protect their institution’s information.
With this increased security, we aim to provide the highest quality learning environment for test takers. Exam taking is already stressful without added worry about data privacy and key encryption. Going forward, this increased security will provide peace of mind to institutions and test takers should a security breach ever occur.
Note: This blog post was updated for clarity on June 23, 2021.