Topic: Yet Another Hardware Wallet Proposal? (Read 3026 times)

Fourtunately, X.509 verification is feasible, even with low-end microcontrollers. The overwhelming majority of X.509 certificates use RSA. RSA signing is indeed difficult, but verification is much, much easier. I estimate that verification of a 2048 bit RSA certificate is no more difficult than ECDSA (using secp256k1) signing.

As a very rough estimate, a modern but low-end 32 bit microcontroller should be able to generate a ECDSA signature in < 0.5 s.

Thanks, yes I agree that the software side is more important initially, although I'm not quite sure how portable ECDSA or other BigNum code would be across different architectures. I know there were some implementations in some of the other hardware wallet code that people have posted that I need to take a look at next, and then I'd probably start by contributing to the other hardware wallets.

Just getting some of my other thoughts out there, and also this was an excuse to mess around in solidworks which is always fun

The first huge milestone in my mind would be to see an open source implementation of the code needed to run on this just as a plain C program that runs on Linux and communicates via stdin/stdout, without depending on anything you wouldn't see in a microcontroller environment.  Then it's just a matter of porting it.

The 128x64 1-bit-color display is a good size to target.  I have VeriFone credit card machines with a similar 128x64 display that could run this app if it existed.

Hello all,

Personally, I think that having a easy-to-use hardware wallet that could realistically replace a credit card in the current PoS environment would go a long way towards making Bitcoin more user-friendly. I am a hardware guy like many others here, and would be really interested in seeing one succeed. I'd like to throw my hat into the ring to create a truly consumer-friendly product - yes, it's Yet Another Hardware Wallet proposal. At the very least, I'll inject some ideas for the next revision of another project.

I am envisioning a device that will be used in payment scenarios in current and near term usage (within the next 2-3 years - i.e. Bitcoin in its current form, without widespread multi-sig, without established payment providers that would offer their own credit - OpenPay maybe?)

• Payment device to/from computer (laptop/desktop etc., usually over USB, permanent connection to the Bitcoin network, maybe a full node.)
• Payment device to/from cell phone (interactive, spotty connection to network)
• Payment device to merchant (POS terminals, vending machines, lightweight connection to the network, possibly non-interactive)
• Device to Device payments
• Device to/from paper wallet payments

Currently the plans should include NFC for android devices and existing (!) merchant PoS terminals, USB OTG for talking with android devices and PCs, its own battery for offline TXs, and a proper keypad for entering keys, payment addresses, etc. This would allow for the widest compatibility and would be able to satisfy all scenarios listed above.

The device should have enough CPU power maybe to do X.509 verification, or at least store public key hashes for existing merchants that are trusted, following the new Payment Protocol standard in development, or Protecting merchants from compromised webservers, or [PROPOSAL] Secure Payment Protocol. This would allow for swipe-style payments for merchants after the first TX.

I would love to go the open source route but after looking at microcontrollers with integrated security, they all require NDAs and I would think open source is a big no-no. Maybe a bitcoin library that also provides a HAL for any hardware RNGs or ECDSA accelerators would be the best way to go. Maybe Maxim MAXQ1050...

Anyways, with the day off (Happy New Year!) I played around in SolidWorks to kind of explore a physical layout: credit card dimensions, but 4 mm thick. It uses a 128x64 OLED display. Also includes a small battery, only 65 mAh, enough for probably about 1-2 hours of powered-on time before needing to be recharged. I may consider E-ink instead for lower power but the displays are slow, expensive, and hard to source. It would include an NFC antenna in the upper right hand corner. I am also open to supporting other weird wireless protocols as well - Dash7 mode 2, 802.15.4, or BitcoinCard-protocol might be interesting.



Anyways, I just wanted to get my thoughts down and open it up for discussion. Perhaps it would work out better just rolling some of this stuff (esp NFC & a battery) into the Piglet or BitSafe hardware wallets.

Thanks, Kevin