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.

Sign up for GitHub

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

Jump to bottom

Sudden data loss on EV #98

Open
szszszsz opened this issue Jul 6, 2020 · 3 comments
Open

Sudden data loss on EV #98

szszszsz opened this issue Jul 6, 2020 · 3 comments
Labels
monitoring prio:high Makes the device difficult to use, or insecure. test
Milestone
v0.57

Comments

@szszszsz
Copy link
Member

szszszsz commented Jul 6, 2020

User reports sudden data loss on Windows 10 on Encrypted Volume. From the description it appears that the AES key was changed. Asking for further details.
@szszszsz szszszsz added monitoring prio:high Makes the device difficult to use, or insecure. test labels Jul 6, 2020
szszszsz added a commit that referenced this issue Dec 30, 2020
@szszszsz
Merge branch 'release-v0.55'
f376b08 
Firmware changes:
- Guard configuration structure access to avoid rare event resulting in data loss
- Mark global variables volatile, where accessed between tasks
- Timeout and reset DMA channels on failure
- Introduce smart card start up delay to favor internal processes
- Increased firmware version to v0.55
- Configuration access refactorization for easier data manipulation

Development:
- Import project to Atmel Studio 7
- Allow to build using Makefile
- Add stub for CMake usage
- Remove obsolete code
- Add initial support for stack guard protection

Connected: #98

Tested on:
- macOS 10.15.2
- Linux Fedora 32
- Windows 10 20H2
with:
- libnitrokey 3.6 (Python test suites; skipped on Windows)
- Nitrokey App v1.4 (manual test)
For tests firmware was built using GCC 4.3.3 (AVR_Toolchain_3.0_124), -O0.
Firmware upgrade and downgrade tested on the previous latest firmware.

Test suite was modified to account TOTP#15 slot being disabled.
@szszszsz
Copy link
Member Author

Should be fixed in v0.55 release. Leaving open for monitoring. To be closed on the next release.

@szszszsz
Copy link
Member Author

szszszsz commented Nov 16, 2021 •
edited
Loading

Unfortunately this problem has reproduced again, on a different OS. Quote from the user's report below:

This most serious recent problem, which caused erasing both data and TOTPs, happened on Dell Precision 7560 with Fedora 34 and following versions of libnitrokey, nitrokey-app and nitrokey storage firmware:

  • libnitrokey: 3.5-5.fc34
  • nitrokey-app: 1.4.2-2.fc34
  • firmware: 0.55

First warning mentioned that (all of a sudden!) encryption keys are missing
and they need to be generated (even though I’ve been using this disk with
encrypted volume and TOTPs for several months already). Thinking that perhaps
there was some update to Nitrokey-App (as I do frequent updates to all
packages), I followed these instructions.
Unfortunately, this still did not allow me to unlock and mount the encrypted
volume, and I received another warning, this time it said “Encrypted volume
is not secure, Select ‘Initialize storage with random data’.”. Again,
not being able to encrypt and mount the volume I use daily in my work, I
clicked ‘yes’, assuming there was some update to Nitrokey-App. However,
upon completion of this, all data and TOTPs got erased; I had to create a
(EXT4) partition all over again.

I expect some data access race condition is still occurring, which was missed during the last time the code was reviewed. This should be found and removed, or the implementation restructured. Having a backup configuration page should help as well.
Firmware side it seems to occur only in a certain usage pattern, or under a heavy load. I do not see how hardware could trigger this behavior (which basically is clearing the user configuration pages).

@szszszsz szszszsz mentioned this issue Nov 16, 2021
Open
@szszszsz szszszsz added this to the v0.57 milestone Nov 16, 2021
@szszszsz
Copy link
Member Author

This was reported recently on the support forum with current firmware, but the cause seem to be in the configuration being lost or overwritten. In general the frequency of the data lost look a lot smaller than it used to be before the latest release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
monitoring prio:high Makes the device difficult to use, or insecure. test
Projects
None yet
Milestone
v0.57
Development

No branches or pull requests
1 participant
@szszszsz