Topic: [ANN] Open Source Java Card Hardware Wallet - Yubikey Neo - two factor with NFC (Read 3327 times)
March 01, 2016, 04:48:19 AM
yes absolutely. It should be easy enough to do - the source code already supports different coin versions.
March 01, 2016, 01:57:36 AM
Is it possible to adapt this for use for an alt coin? I realize that it's not just the card, but it has to have a wallet app to interface with as well.
June 02, 2015, 03:48:21 PM
The new shiny HD version is now compatible with Electrum. Highly experimental of course, mostly done to demonstrate the portability of the common API.
There is also a new Eligibility applet available to test the performance of your favorite Java Card. Spoiler, it probably won't be pretty.
There is also a new Eligibility applet available to test the performance of your favorite Java Card. Spoiler, it probably won't be pretty.
March 09, 2014, 06:45:15 PM
Good, welcome aboard, enjoy your stay 
just be aware that the code is now significantly different from the native implementation following the implementation of HD Wallets (and deterministic signatures on a smaller extent), so client integration cannot be shared between both implementations any more.
Implementing HD Wallets support in Java Card is currently a major pain, first because SHA 512 is not supported, second because there is no public API for big numbers manipulation, and third because it's not possible to use prepared ECC private keys in the public API either. The last two could probably be done with a proprietary API though, and http://www.fi.muni.cz/~xsvenda/bin/ can be a start for the first one.
just be aware that the code is now significantly different from the native implementation following the implementation of HD Wallets (and deterministic signatures on a smaller extent), so client integration cannot be shared between both implementations any more.
Implementing HD Wallets support in Java Card is currently a major pain, first because SHA 512 is not supported, second because there is no public API for big numbers manipulation, and third because it's not possible to use prepared ECC private keys in the public API either. The last two could probably be done with a proprietary API though, and http://www.fi.muni.cz/~xsvenda/bin/ can be a start for the first one.
March 09, 2014, 03:37:57 AM
I have a yubikey neo that I haven't even used yet, maybe I will mess around with this.
November 25, 2013, 08:22:09 AM
Quick update, the RIPEMD160 code has been improved significantly (down from 1200 ms to 300 ms)
November 21, 2013, 02:01:28 PM
Thanks. Note that the RIPEMD implementation is pretty horrible and will take approximately 1 second to hash 32 bytes. This might be improved (a bit) by inlining everything.
November 21, 2013, 11:07:02 AM
Hey, that's pretty cool, I like the idea of using the contactless interface for confirmation. I also like the fact that you've implemented RIPEMD in JavaCard, I couldn't find any NXP JCOP-based chips that had it natively implemented. Good work!
November 20, 2013, 07:35:09 PM
Creating a separate thread for that, as the original BTChip one is dedicated to the custom implementation we design
https://github.com/btchip/btchipJC
This project is an Open Source implementation of the BTChip specification, running on a Java Card (typically a Yubikey Neo)
The physical isolation between the contact and contactless interfaces is used to create a transaction approval mechanism : start a transaction on a computer, tap the dongle on a phone, read the transaction details and a PIN, plug back the dongle into the computer, enter the PIN to approve and sign.
The contactless interface can also be used to perform transactions on a controlled wallet (maximum transaction amount, maximum fees, maximum change)
This is strictly developer material for the time being (no client support), but hopefully will motivate us or someone else to start working on it seriously
https://github.com/btchip/btchipJC
This project is an Open Source implementation of the BTChip specification, running on a Java Card (typically a Yubikey Neo)
The physical isolation between the contact and contactless interfaces is used to create a transaction approval mechanism : start a transaction on a computer, tap the dongle on a phone, read the transaction details and a PIN, plug back the dongle into the computer, enter the PIN to approve and sign.
The contactless interface can also be used to perform transactions on a controlled wallet (maximum transaction amount, maximum fees, maximum change)
This is strictly developer material for the time being (no client support), but hopefully will motivate us or someone else to start working on it seriously
Jump to: