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

Issues with unlocking encrypted volume on macOS #44

Closed
szszszsz opened this issue Aug 26, 2017 · 6 comments
Closed

Issues with unlocking encrypted volume on macOS #44

szszszsz opened this issue Aug 26, 2017 · 6 comments
Labels
bug prio:high Makes the device difficult to use, or insecure.
Milestone

Comments

@szszszsz
Copy link
Member

szszszsz commented Aug 26, 2017

Unlocking the encrypted volume fails, the device keeps returning busy status for a time and it unlocks the volume after all (Nitrokey App shows error and reconnects; sometimes returning WRONG_PASSWORD error code), but with constantly flashing both red and green LEDs.
After locking the device and unlocking the volume it works (as have in previous releases), but setting up hidden volume causes constant BUSY status replies with no LED activity.
Occasionally device returns BUSY right after insertion.

OS: Sierra 10.12.6
Storage: v0.48
Frequency: always
Nitrokey App v1.1

Adding high priority since issue blocks the use of main functionality.

Scenario:

  1. Run Nitrokey App
  2. Insert Storage device
  3. Wait 10 seconds for device initialization
  4. Try to unlock encrypted volume

Logs:
Issue occurrence - almost 1 minute of BUSY status: issue_44-encrypted_volume_unlock-3.txt
Retest on v0.47: issue_44-encrypted_volume_unlock-v0.47.txt

@szszszsz szszszsz added bug prio:high Makes the device difficult to use, or insecure. labels Aug 26, 2017
@szszszsz
Copy link
Member Author

szszszsz commented Aug 26, 2017

Confirmed that the issue is not occurring on firmware v0.47.
For a while after the volume unlock both LEDs were flashing as on v0.48 at the time of the issue occurrence.

@szszszsz
Copy link
Member Author

I have cut out most of the BUSY statuses by making sure buffer data is properly refreshed with libnitrokey on OS side. However there is still the problem of reporting sometimes wrong password status by device on unlocking encrypted volume.

@szszszsz
Copy link
Member Author

To retest on latest Nitrokey App.

@szszszsz szszszsz added the test label Oct 25, 2017
@szszszsz
Copy link
Member Author

szszszsz commented Oct 25, 2017

BUSY status is still occurring. After timeout and re-connection device is responding. Issue progress flow looks familiar to results of the libnitrokey tests.
Same behavior on Nitrokey App v0.6.1 and v0.5.1

@szszszsz
Copy link
Member Author

Note the issue is occurring right after insertion.
When some time passes after the connection it looks like issue stops showing up. I have just seen that behavior, once and accidentally after 1 hour while doing another tests.

@szszszsz
Copy link
Member Author

szszszsz commented Oct 30, 2017

Unfortunately no working workaround could be found on Nitrokey App / libnitrokey side.
Tested also on older Nitrokey App versions - v0.6.3 and v0.5.1.

@szszszsz szszszsz removed the test label Oct 30, 2017
@szszszsz szszszsz added this to the v0.49 milestone Dec 11, 2017
@jans23 jans23 closed this as completed Jan 22, 2018
NKelias pushed a commit to NKelias/nitrokey-storage-firmware that referenced this issue May 25, 2019
Remove most of the build warnings. src/Library files are not impacted.
Warnings generated with -Wall. Some of the -Wextra were solved too.
Now any warning in our codebase (not src/Library; using -Wall switch)
would make a compilation error.
Compilation made on GCC 6.3.1 and 4.9.3. The latter build used for
testing.

Tested against:

    libnitrokey v3.3-12-g391a276 (pytest -sv test_pro.py --count 3)
    nitrokey-hotp-verification v1.0 (./test_hotp)

Closes Nitrokey#44
Fixes Nitrokey#40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug prio:high Makes the device difficult to use, or insecure.
Projects
None yet
Development

No branches or pull requests

2 participants