Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate OpenBSD SSH protections against side-channel attacks #88

Closed
awnumar opened this issue Jun 21, 2019 · 1 comment
Closed

Investigate OpenBSD SSH protections against side-channel attacks #88

awnumar opened this issue Jun 21, 2019 · 1 comment
Assignees
Labels

Comments

@awnumar
Copy link
Owner

@awnumar awnumar commented Jun 21, 2019

https://marc.info/?l=openbsd-cvs&m=156109087822676&w=2

Commit: openbsd/src@707316f

@awnumar awnumar self-assigned this Jun 21, 2019
@awnumar
Copy link
Owner Author

@awnumar awnumar commented Jul 15, 2019

Essentially what they do is store a 16 KiB "prekey" and use it to derive the actual key when it is needed. The rationale is that the prekey has to be recovered with high accuracy by the attacker and current generation side-channel attacks are slow and have error-rates that make this unlikely.

In order to implement something like this ourselves, I was thinking something along the lines of:

  1. Have each partition of a Coffer object be a whole page size in length.
  2. The data value that is derived when "unlocking" this object would be hashed to get the 32 byte key.

Some issues:

  1. Iterating over a whole page every 8ms is a lot more computationally expensive than iterating over 32 bytes.
  2. Hashing the data would require re-writing the hashing algorithm to use securely-allocated memory, as the output is used as a key.
  3. I'm not confident that the scheme would provide substantial security gains over current Coffer objects.
  4. The value would still be vulnerable to side channel attacks in its "unlocked" form.

The current scheme changes the value very rapidly and so exfiltrating both partitions fast enough to recover the key may be difficult. We also minimise the time the unlocked key spends existing.

I may revisit this in the future but for now our current scheme seems sufficient.

Loading

@awnumar awnumar closed this Jul 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant