Would suggest 2 modes instead:
1: Retailer/end user mode: The device will require a momentarly physical button to be held down for it to sign a outgoing tx. If a attempt is made to sign a tx without button held down, it will disconnect USB interface and beep each Xth second. (Xth second needs to be carefully selected so its not annoying, but its "hey someone is trying to steal your funds").
To reset, the user needs to disconnect the device and reconnect.
There should not be able to discern if the physical button is being pressed or not, from the USB interface, before its "too late", so a trojan cannot wait until the button is being pressed and "piggyback" that.
It will only sign one TX for each button press, for sending multiple TX, you would need to release the button and press again.
2: Exchange/onlinewallet mode:
The device will keep a database of users, hashed password, their balance, and their receiving adress.
The device will NOT sign a TX that would cause a user's balance to go negative.
Along with a TX to it for sign, the requestor needs to supply a username/password of whoever's account to use.
The device also needs someway to verify incoming funds. So the device in some way needs to know the blockchain, or some other way to verify that a incoming funds is real, and then populate the user's balance, then automatically "sweep" this adress to the exchange/onlinewallet's main adress/hot wallet, then delete privkey and adress from user storage. Will also send out signed transactions for the host to just send out on the network. (sweep transactions)
It does not need to save the whole blockchain, the device would only need to save the 6 last blocks, because when it have seen a transaction and populated that user's balance with the money, the block is no longer needed for the device in question.
There also needs to be meta functions:
create account - creates account with 0 balance
delete account - deletes account if correct password is specifyed, but ONLY if the balance is exactly 0.
change password - changes password of a user.
update user balance - Can be used to deduct money from user, but not add.
The physical button will in this case function for password reset. While its held down, the device will accept any "old" password for changing password on a user (and not just the correct password). So basically, if a end user forgot his onlinewallet/exchange password, this would require manual intervention, where the site operator initiates a password reset, then physically are present at the HSM to hold down the button and then completes password reset, then gives the new password to the end user.
The physical button held down will also make the device accept any TX without any user, and this is when site operator collects fees from the main wallet.
The physical button also needs to be held down for it to register a "checkpoint" block, which will be required during initalization.
The physical button held down will also allow "update user balance" to add funds.
The security in this is: Lets say bitcoinica case.
Lets say bitcoinica consist of 180 users with 100 BTC in each wallet. The HSM device will then have a "hot wallet" (one address) of 18 000 BTC and 180 users inside.
A hacker that hacks into bitcoinica server, will not know any user's password because they are hashed at the site database. The hacker needs to crack these to get the unhashed password to authenticate to the HSM with. Lets say the hacker manages to crack 5 users.
The hacker will now use password for user 1. He now tries to get the HSM to sign a transaction for 18 000 BTC. But the device sees "the hot wallet contains 18 000 BTC but user 1 only have a share of these of 100 BTC" and will reject the transaction.
The hacker only have the choice of signing a sum of under 100 BTC.
So in this case, he would only be able to steal 500 BTC (5 users with 100 BTC in their account each)
For the hacker to be able to push larger transactions, he would need to crack a user that have depoisted a large sum at the exchange/onlinewallet service. And users with large BTC sums tend to have secure passwords = fail for the hacker.
So basically, the device would accept a 10 000 BTC transaction, ONLY if the user that is specifyed in the signing request, have 10 000 BTC in his account.
Basically this would solve everything without delays for end users and without manual intervention at "correct" large transactions.
The "password" used to authenticate at the HSM for a specific end user can be anything, a encrypted string or whatever, even a expected "reply" from a security token or whatever.NOTE: Dont misunderstand this now. With "balance", I DONT mean the wallet balance at the end user. I mean the balance the user have in a "virtual" account at the online exchange or online wallet service. This are NOT a actual bitcoin wallet balance, its just a stored-value of whatever a end user can spend at that site.