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

Locking and unlocking a factory-reset device blocks encrypted storage #80

Open
robinkrahl opened this issue Jan 16, 2019 · 4 comments
Open

Comments

@robinkrahl
Copy link

During testing, I noticed that after performing these commands in this order, I can no longer unlock the encrypted storage:

  • factory reset
  • build AES key
  • lock device
  • lock encrypted storage

Example code:

#include <assert.h>
#include <libnitrokey/NK_C_API.h>

int main()
{
	NK_set_debug(true);
	assert(NK_login_auto() == 1);
	assert(NK_factory_reset("12345678") == 0);
	assert(NK_build_aes_key("12345678") == 0);
	assert(NK_lock_device() == 0);
	assert(NK_lock_encrypted_volume() == 0);
	assert(NK_unlock_encrypted_volume("123456") == 0);
	return 0;
}

I attached the debugging output.
out.txt

@szszszsz
Copy link
Member

szszszsz commented Jan 16, 2019

Hi! Nice test case.
Looking at the log, my guess is either AES-key generation is not finished, or it was overwritten while locking the device (not sure the latter is possible). About error code 10:

src/OTP/report_protocol.h:154:

#define CMD_STATUS_AES_DEC_FAILED           10

For zeroed AES key case, a 100 code was used, so this might be something other.
Anyway, this needs to be fixed.

@robinkrahl
Copy link
Author

I think the problem is that build_AES_key is called directly after the factory reset. I found another snippet that reproduces the problem:

#include <assert.h>
#include <unistd.h>
#include <libnitrokey/NK_C_API.h>

int main()
{
	NK_set_debug(true);
	assert(NK_login_auto() == 1);
	assert(NK_factory_reset("12345678") == 0);
	sleep(2);
	assert(NK_build_aes_key("12345678") == 0);
	assert(NK_enable_password_safe("123456") == 0);
	return 0;
}

With a two second delay, I get an error (and no log entries about the Nitrokey being busy while generating the AES key). With three seconds, it works as expected.

@robinkrahl
Copy link
Author

cc @d-e-s-o

@szszszsz
Copy link
Member

My proposition of a workaround is to incorporate the delay into the libnitrokey itself for an older firmwares, and until this one will not be fixed. Later on it could be removed.
I believe on the Storage side itself the delay set is not sufficient to complete the parallel task, hence the whole issue.

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

No branches or pull requests

2 participants