-
Notifications
You must be signed in to change notification settings - Fork 255
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
Added support of (open)hardware cryptographic module "Trezor One". The second try. #247
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks very good already! Some small changes requested.
One thing I noticed while testing: When the Trezor is in bootloader mode (press both buttons and connect USB), gocryptfs -init -trezorkey
hangs.
What happens when two Trezors are connected?
internal/readpassword/trezor.go
Outdated
// This values were generated using command: | ||
// dd if=/dev/random of=/dev/stdout bs=48 count=1 2>/dev/null | hexdump -e '8/1 "0x%02x, " "\n"' | ||
var ( | ||
TREZOR_DUMMYKEY = []byte{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem with a "random" value like this is that you can never know if it has been chosen for a particular reason. Like, maybe this exact value exposes a weakness? No one can tell.
Let's just go with 16 zeros. AES handles that just fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm afraid of kinda randbow tables (but to optimize of getting encryption keys instead of getting hash function initial values) for zero-filled data. I mean somebody like NSA could have optimized ways of getting keys using known blocks of encrypted and decrypted data where the encrypted data is a zero-filled data. I understand that sounds crazy, but I feel more secure to use random data… On the other hand I agree with your argument (I had the same thought while generating that random numbers) and zero-filled data looks more trustfully. OK :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can go for something like "gocryptfs.trezor" or "trezor.trezor.tr" or "tttttt..." if you prefer, I'm fine with that!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, that's sounds more reassuringly, thanks)
internal/readpassword/trezor.go
Outdated
0xab, 0x05, 0x3b, 0x12, 0xff, 0x4e, 0xa8, 0x8b, | ||
0x5b, 0x58, 0x0a, 0x8e, 0x42, 0xcf, 0x5e, 0x20, | ||
} | ||
TREZOR_NONCE = []byte{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to slip-0011.md, the IV is optional, and I don't see that it adds security - let's skip it.
internal/readpassword/trezor.go
Outdated
0xcc, 0xb6, 0xb2, 0xcd, 0xbc, 0x4a, 0xb6, 0xcb, | ||
} | ||
TREZOR_KEY_NAME = "gocryptfs" | ||
TREZOR_KEY_DERIVATION_PATH = `m/10019'/0'/0'/0'` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These can be const
. Also, please follow Go naming like trezorKeyName
.
There are a few places in gocryptfs that use this style, like PATH_MAX
, but this is only when there is Linux C define copied.
As you suggested, let's use m/10019'/0'
for gocryptfs. I see no problem with you using m/10019'/1'
and higher.
Oh, one more thing: I was looking at https://goreportcard.com/report/github.com/xaionaro-go/cryptoWallet :
|
Ok. I'll fix everything soon and will test with two Trezors. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mentioned problems were fixed.
Fixed. Please restart the Travis checks. |
Don't have my computer right now, but you could do git commit --amend --date=now This only updates the timestamp of the commit, but this changes the git hash, and travis will see a new commit and rebuild. |
Nice trick. Thanks. |
goreportcard looks excellent now, and you also added a link to godoc, very nice! The logic for finding out if we have more than one Trezor seems to have a small problem:
I added a little debug output to see what is going on:
Looks like this is because Trezor presents two USB interfaces: You can also see this in
|
I see. Indeed I forgot to test it after that change. I will handle that today-tomorrow. |
I've just tried to connect one initialized Trezor and one not initialized one and got this:
The not initialized device has only one interface, the initialized device has two interfaces. Interface 1 seems to be an U2F interface. The problem is fixed. Two connected devices:
One connected device:
|
Maybe changes not pushed? I'm on 06e92a9 and still see the error. |
The fix was in cryptoWallet. |
Well, that explains things. Works better now. Can you reproduce this issue?
|
Normal mode:
Bootloader mode:
|
Quoting https://doc.satoshilabs.com/trezor-tech/api-workflows.html#initialize-features :
It looks like libWallet does not do this. This is why it does not notice that the Trezor is in bootloader mode ( |
I have collected some more details at #248 . |
This also checks if the device is initialized. Relates to: rfjakob#248
Thank you for the details. The problem is fixed. |
Works fine here now, thanks! In the meantime, I have noticed a flaw in my decrypt-constant-string approach: The unlock key for all filesystems is the same. If an attacker manages to sniff the USB traffic and get the unlock key, hey can unlock all other gocryptfs filesystems that were secured with the same Trezor. To fix this, I have added a random, per-filesystem I have squashed and rebased your changes on top of this fix and pushed into the trezorpayload branch. Your changes are in commit a2e1cc7 . Would you mind giving it a test-drive and see if I have broken something in the rebase? |
Ok, nice solution.
Ok, sure. Also I received a notification that Trezor T have arrived. I'll get it and test with it soon. |
A little offtop: I've just received "Trezor T". Are you able to get it work? It hangs on my machine on any operation (including UPD: It appears it was required to just install a new version of python-trezor (it was updated recently). |
It seems that Trezor is going to webusb [and away from usbhid :(] |
The Trezor T seems to have two USB interfaces:
Interface 1 is still HID. |
I only ever tested the Trezor T via trezor.io. I now tried this with the tesoro example: ~/go/src/github.com/conejoninja/tesoro$ git diff
diff --git a/example/main.go b/example/main.go
index 89f7c44..d525bbc 100644
--- a/example/main.go
+++ b/example/main.go
@@ -33,7 +33,7 @@ func main() {
// 0x534c : 21324 vendor
// 0x0001 : 1 product
// 0x00 : Main Trezor Interface
- if info.Vendor == 21324 && info.Product == 1 && info.Interface == 0 {
+ if info.Vendor == 0x1209 && info.Product == 0x53c1 && info.Interface == 1 {
numberDevices++
var t transport.TransportHID
t.SetDevice(device) Finds the device, but hangs on init:
|
Merged into master, but protected by a build tag for now. You can compile gocryptfs with trezor support using
It looks like it does not compile at the moment due to changes in tesoro:
|
Thank you!
Fixed. See xaionaro-go/cryptoWallet#2 |
Added support of Trezor T within cryptoWallet. I'll make a new PR to gocryptfs, soon. |
Implemented the support of Trezor devices.