Bf-tweak-table build issues
Closed this issue · 5 comments
Hi, I am interested in SEV memory security and I have recently read the paper "SEVurity: No Security Without Integrity - Breaking Integrity-Free Memory Encryption with Minimal Assumptions". I am trying to understand the principle behind guessing the tweak constants. I would like to build Bf-tweak-table and run it on my machine to see the result.
However, I am facing an issue with the code and I am getting an error
SEVurity/tweak-tools/bf-tweak-table/bf_tweak_base.c:16:35: fatal error: tweak.h: No such file or directory.
Is this error due to the missing of a necessary file? I kindly request your help to provide me with the necessary information to complete this experiment.
Thank you for your time and effort. I look forward to your response.
Sorry, something with my github notifications went wrong. I will look into this and get back to you.
Looking at old code is really humbling...
The file is indeed missing from the repo.
It should look like this
#ifndef TWEAK_H
#define TWEAK_H
//MAX_TWEAKS as in bf_tweak_base.c
uint8_t tweaks[MAX_TWEAKS][16] = {
{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
....
};
#endifThis should be filled with all tweak values that are already known, i.e. it is intended to resume the reversing process after some initial progress. Initially, it should be set to all zero. This is partially talked about in the "enter all known tweaks part" in the readme (although it erroneously says tweaks.c instead of tweaks.h there)
This array is mainly used by calc_tweak.
I hope this helps. Feel free to ask follow up questions.
I will push a version that is working out of the box when I find some spare time
Thank you for being so generous. By the way, I was wondering if the principle involves tweaking the value for every 4 bytes repeated, so that we can reduce the guess time from 128 bits to 32 bits. Additionally, I was wondering if we can assume that if we cannot find the solution from 0000 to FFFF, then the machine doesn't have this bug?
Furthermore, I noticed that in your paper, you mentioned that this bug was fixed in the Zen 2 architecture. I was wondering if any new hardware has been added or if the fix was simply implemented through software updates?
Thank you in advance for your time and assistance.
By the way, I was wondering if the principle involves tweaking the value for every 4 bytes repeated, so that we can reduce the guess time from 128 bits to 32 bits.
Yes, assuming the 4 byte repetition, the entropy is only 32 bits. However that means 0 to 0xff_ff_ff_ff (not ff_ff). This ist part of the main loops stop condition
Additionally, I was wondering if we can assume that if we cannot find the solution from 0000 to FFFF, then the machine doesn't have this bug?
Assuming that the crypto system stayed the same: yes.
Furthermore, I noticed that in your paper, you mentioned that this bug was fixed in the Zen 2 architecture. I was wondering if any new hardware has been added or if the fix was simply implemented through software updates?
We where also wondering about that. In Section 3.A (at the end) we had this observation that the tweaks seemed to have changed after doing some firmware + bios updates on one of our systems.
Thank you so much for your support. It means a lot to me. :)