Author Topic: How will Keyhotee guard the usage of private key for ID?  (Read 4797 times)

0 Members and 1 Guest are viewing this topic.

Offline luckybit

  • Hero Member
  • *****
  • Posts: 2921
    • View Profile
  • BitShares: Luckybit
Keyhotee asks you for your password when you start the program and will keep your private key in memory only.  On disk it is always encrypted.

In order to process incoming messages your private key needs to be 'live' at all times.  There is no way around that. 

With the wallet system you only need your private key for sending money.

Bottom line, you are relying on the physical security of your computer and OS while Keyhotee is open.    Any bright ideas on how to improve that?

Might be a good idea to make use of the trusted platform module.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline Troglodactyl

  • Hero Member
  • *****
  • Posts: 960
    • View Profile
What if each key had a parent key, a list of subkeys, a list of supported application GUIDs and a human readable subtitle string?  All reputation alterations and checks would propagate up to the root.  Either a key's own signature or that of a parent would be necessary for revocation, and both signatures would be required to form new subkey relationships.  Subkeys could be used on lower security devices when necessary to avoid risking the primary, particularly if it were a founder's ID.  The GUID list would inform others of what currencies could be received by the particular key, as well as what other applications the key supported.  The subtitle string could be used to label a key as home, work, or mobile, or to label a key for contributions to a particular project.

Subkeys wouldn't need names registered in the blockchain, since they don't have their own reputation.

Offline HackFisher

  • Hero Member
  • *****
  • Posts: 883
    • View Profile
I happen to read some posts with similar ideas to resolve similar questions from PPC community, they might be helpful to the topic, honor belongs to @clar

Just quote and add the link here, still not fully understand them though.

Quote

https://bitcointalk.org/index.php?topic=115608.msg1319290#msg1319290

Quote from: Jutarul on November 06, 2012, 03:20:01 AM
Maybe we should organize a bounty for this?

I think you need to consider this 'feature' more carefully before raising a bounty. It may be a serious 'bug' if implemented poorly.

Giving away a copy of the stake signing key has no risk for the user whatsoever, but the signing keys are valuable to an attacker. Therefore, an attacker could purchase up all the signing keys really
cheap and attack the network. The attack could not be stopped. (attacker could refuse to allow anyone to include txns that revoke the sign key). This must be avoided. Offline stake creation also seems like a bad idea for similar reasons.

Stake signing should not be a risk-free process. Risk-free private keys should not exist.

A better solution is to make two keys: one high-functionality high-risk key, one low-functionality low-risk key.

a) The high risk key can do anything. The high risk key can also move all the coins at once, invalidating the low risk key.

b) The low risk private key can spend 0.01% of its balance per block. Enforce this as follows. Every txn signed by the low risk key must send at least 10000 satoshis to its own public key address for every 1 satoshi sent to another address or used as a txn fee. [this is a block validity rule; txns that don't obey this cannot be included in blocks] This key can then be depleted at a maximum rate of about 1.5% per day.The low risk key can also provide proof-of-stake.  You can expose this key to the network at low risk. You might share it with a well-trusted party. You wouldn't share this key with an anonymous individual however. 

Each wallet should list two types of balances: Spending and saving

1) Savings wallets are unencytped. Savings wallets have low risk private keys online and unencrypted and high risk private keys in cold storage. Savings wallets try to provide PoS.

2) Spending wallets are optionally encrypted. They should have both the low risk private key and the high risk private key online. These wallets cannot provide PoS if they are encrypted.

Users can shift coins back and forth as needed. This is a good improvement for three reasons.

1) It makes stake provision safer

2) It makes the currency safer to use in general (i.e. now it would be like you can call the credit company and report your private key stolen. Think how many unlucky bitcoin users have wanted to do this at some point.)

3) Convenience is maintained because the spending wallet still provides the traditional functionality.

-----------------------
https://bitcointalk.org/index.php?topic=194054.0

Abstract: A proposal to relieve stake minter the risk of running online hot wallet.

Description: This proposal is simpler than the previous dual-key proposal [1]. A special transaction type called cold-locked transaction is introduced so that a designated spending address is specified in its first output. Protocol enforces that, spending of any of the outputs in the transaction must be sent to this designated address, or to itself (for stake generation purpose). When stake is generated, the stake transaction is also cold-locked and the designated key in stake must match all designated keys where all the inputs come from.

How hot wallet is protected:

By providing a cold-wallet address as the designated spending address in cold-locked transactions, stake minter can now run their entire balance online in a hot wallet to earn 1% annual interest with minimum risk, while providing maximum security to the entire network. This would allow even the exchanges, pools, and other online wallet providers to participate in network protection without risking public assets, and reduce fees or even pay interest to its users.

For public review and discussion.

References:
[1] https://bitcointalk.org/index.php?topic=115608.0
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline HackFisher

  • Hero Member
  • *****
  • Posts: 883
    • View Profile
Good idea! 

I think this idea may also apply to prove of stake, we may use a subkey for the purpose of verifying the owner of stake, this subkey is for this purpose only, cannot do transactions, so we can keep mainkey offline and safe.

Sent from my GT-N7100 using Tapatalk

I don't quite sure if this is technically possible. Sounds nice idea, too!

Further more, I think we could extend this idea of mainkey-subkey to a more common model/service, used to integrate different DAC services, it can separate the risk of lost private key, increase the dynamic flexibility of Keyhotee because key relationship are stored/broadcast through blockchain.

For Keyhotee, I don't know finally how will it be implemented technically. But I think it would be very interesting if not just simple using a subkey for some purpose(e.g. send emails). How about using tag for a subkey, the tag represent some DAC service(e.g. Integrate bitcoin wallet to send BTCs), we may not want to share one key for both email and btc wallet.

We can even import the wallet key of Bitcoin as a subkey of Keyhotee, just binding to some tag and the main key, in that way, we can implement great features like direct send someone BTC just need to know his Keyhotee ID(if he has a bitcoin tag binded), and SSO, keep his btc wallet dat private. This is implemented by query his Bitcoin address by query the subkey bind to "Bitcoin" Tag of Keyhotee ID, balabala...... I can imagine more cases like this, I saw a snapshot of Keyhotee wallet, there seems already have similar feature, I have no idea whether they are implemented this way, maybe its time to views the source codes.

Willing to know more details about this, I have more interest in Keyhotee now,  for its potential to guard the privacy and ability to integrate DACs as ID management.
« Last Edit: December 09, 2013, 02:48:13 pm by HackFisher »
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline coolspeed

  • Hero Member
  • *****
  • Posts: 536
    • View Profile
    • My Blog
Good idea! 

I think this idea may also apply to prove of stake, we may use a subkey for the purpose of verifying the owner of stake, this subkey is for this purpose only, cannot do transactions, so we can keep mainkey offline and safe.

Sent from my GT-N7100 using Tapatalk

I don't quite sure if this is technically possible. Sounds nice idea, too!
Please vote for  delegate.coolspeed    dac.coolspeed
BTS account: coolspeed
Sina Weibo:@coolspeed

Offline HackFisher

  • Hero Member
  • *****
  • Posts: 883
    • View Profile
Keyhotee asks you for your password when you start the program and will keep your private key in memory only.  On disk it is always encrypted.

In order to process incoming messages your private key needs to be 'live' at all times.  There is no way around that. 

With the wallet system you only need your private key for sending money.

Bottom line, you are relying on the physical security of your computer and OS while Keyhotee is open.    Any bright ideas on how to improve that?

I really want to store the private key offline.
How about this way.

We use 2 private key,mainkey and subkey,with different power(or we can say:usage).
They work like this.

1,I generate a mainkey on an offline PC,then I use it to register my kehotee ID.
mainkey<->kehotee ID

2,I generate a subkey and sign this information(subkey's publickey + "active subkey") with my mainkey on offline pc.
then I broadcast this info to p2pnet.I use subkey to login,decrypt, signature and etc.
mainkey->active subkey
subkey->login
subkey->send mail
subkey->read mail
subkey->delete my mail from p2pnet

3,If my subkey was lost or leaked,I can sign information(subkey's publickey + "destroy subkey") with my mainkey
and  broadcast it to p2pnet.Attacker maybe already see my history mail,but he cannot do anything more
when I destroyed my old subkey and active a new subkey.
Most important thing is,I don't have to destroy my kehotee ID,Specifically my founder ID.And Attacker cannot
destroy my kehotee ID with only subkey too.

mainkey->destroy subkey
mainkey->destroy ID

4,My keyhotee ID is totally safe now.
We can make more function with mainkey and subkey.

:-)

Good idea! 

I think this idea may also apply to prove of stake, we may use a subkey for the purpose of verifying the owner of stake, this subkey is for this purpose only, cannot do transactions, so we can keep mainkey offline and safe.

Sent from my GT-N7100 using Tapatalk
« Last Edit: December 08, 2013, 02:51:59 am by HackFisher »
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline guang384

  • Jr. Member
  • **
  • Posts: 21
    • View Profile
Keyhotee asks you for your password when you start the program and will keep your private key in memory only.  On disk it is always encrypted.

In order to process incoming messages your private key needs to be 'live' at all times.  There is no way around that. 

With the wallet system you only need your private key for sending money.

Bottom line, you are relying on the physical security of your computer and OS while Keyhotee is open.    Any bright ideas on how to improve that?

I really want to store the private key offline.
How about this way.

We use 2 private key,mainkey and subkey,with different power(or we can say:usage).
They work like this.

1,I generate a mainkey on an offline PC,then I use it to register my kehotee ID.
mainkey<->kehotee ID

2,I generate a subkey and sign this information(subkey's publickey + "active subkey") with my mainkey on offline pc.
then I broadcast this info to p2pnet.I use subkey to login,decrypt, signature and etc.
mainkey->active subkey
subkey->login
subkey->send mail
subkey->read mail
subkey->delete my mail from p2pnet

3,If my subkey was lost or leaked,I can sign information(subkey's publickey + "destroy subkey") with my mainkey
and  broadcast it to p2pnet.Attacker maybe already see my history mail,but he cannot do anything more
when I destroyed my old subkey and active a new subkey.
Most important thing is,I don't have to destroy my kehotee ID,Specifically my founder ID.And Attacker cannot
destroy my kehotee ID with only subkey too.

mainkey->destroy subkey
mainkey->destroy ID

4,My keyhotee ID is totally safe now.
We can make more function with mainkey and subkey.

:-)

nice!
PTS-PjnA9FckbPWYddRnhpa23vUKMemnVtdwib
BTC-15Dak6X4T1h7EiswEkJvy5Zyx4hbZuFa22

Offline bytemaster

Keyhotee asks you for your password when you start the program and will keep your private key in memory only.  On disk it is always encrypted.

In order to process incoming messages your private key needs to be 'live' at all times.  There is no way around that. 

With the wallet system you only need your private key for sending money.

Bottom line, you are relying on the physical security of your computer and OS while Keyhotee is open.    Any bright ideas on how to improve that?

I really want to store the private key offline.
How about this way.

We use 2 private key,mainkey and subkey,with different power(or we can say:usage).
They work like this.

1,I generate a mainkey on an offline PC,then I use it to register my kehotee ID.
mainkey<->kehotee ID

2,I generate a subkey and sign this information(subkey's publickey + "active subkey") with my mainkey on offline pc.
then I broadcast this info to p2pnet.I use subkey to login,decrypt, signature and etc.
mainkey->active subkey
subkey->login
subkey->send mail
subkey->read mail
subkey->delete my mail from p2pnet

3,If my subkey was lost or leaked,I can sign information(subkey's publickey + "destroy subkey") with my mainkey
and  broadcast it to p2pnet.Attacker maybe already see my history mail,but he cannot do anything more
when I destroyed my old subkey and active a new subkey.
Most important thing is,I don't have to destroy my kehotee ID,Specifically my founder ID.And Attacker cannot
destroy my kehotee ID with only subkey too.

mainkey->destroy subkey
mainkey->destroy ID

4,My keyhotee ID is totally safe now.
We can make more function with mainkey and subkey.

:-)
good idea

I like this idea... implementing it will double the bandwidth and storage costs of the network, but it would dramatically increase security and provide much better protection for your identity.   In fact, so much better that I might be tempted to slip the release date to include it.    Thanks, send me a PTS address for a tip. 
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline coolspeed

  • Hero Member
  • *****
  • Posts: 536
    • View Profile
    • My Blog
Keyhotee asks you for your password when you start the program and will keep your private key in memory only.  On disk it is always encrypted.

In order to process incoming messages your private key needs to be 'live' at all times.  There is no way around that. 

With the wallet system you only need your private key for sending money.

Bottom line, you are relying on the physical security of your computer and OS while Keyhotee is open.    Any bright ideas on how to improve that?

I really want to store the private key offline.
How about this way.

We use 2 private key,mainkey and subkey,with different power(or we can say:usage).
They work like this.

1,I generate a mainkey on an offline PC,then I use it to register my kehotee ID.
mainkey<->kehotee ID

2,I generate a subkey and sign this information(subkey's publickey + "active subkey") with my mainkey on offline pc.
then I broadcast this info to p2pnet.I use subkey to login,decrypt, signature and etc.
mainkey->active subkey
subkey->login
subkey->send mail
subkey->read mail
subkey->delete my mail from p2pnet

3,If my subkey was lost or leaked,I can sign information(subkey's publickey + "destroy subkey") with my mainkey
and  broadcast it to p2pnet.Attacker maybe already see my history mail,but he cannot do anything more
when I destroyed my old subkey and active a new subkey.
Most important thing is,I don't have to destroy my kehotee ID,Specifically my founder ID.And Attacker cannot
destroy my kehotee ID with only subkey too.

mainkey->destroy subkey
mainkey->destroy ID

4,My keyhotee ID is totally safe now.
We can make more function with mainkey and subkey.

:-)

good idea
Please vote for  delegate.coolspeed    dac.coolspeed
BTS account: coolspeed
Sina Weibo:@coolspeed

Offline logxing

Keyhotee asks you for your password when you start the program and will keep your private key in memory only.  On disk it is always encrypted.

In order to process incoming messages your private key needs to be 'live' at all times.  There is no way around that. 

With the wallet system you only need your private key for sending money.

Bottom line, you are relying on the physical security of your computer and OS while Keyhotee is open.    Any bright ideas on how to improve that?

I really want to store the private key offline.
How about this way.

We use 2 private key,mainkey and subkey,with different power(or we can say:usage).
They work like this.

1,I generate a mainkey on an offline PC,then I use it to register my kehotee ID.
mainkey<->kehotee ID

2,I generate a subkey and sign this information(subkey's publickey + "active subkey") with my mainkey on offline pc.
then I broadcast this info to p2pnet.I use subkey to login,decrypt, signature and etc.
mainkey->active subkey
subkey->login
subkey->send mail
subkey->read mail
subkey->delete my mail from p2pnet

3,If my subkey was lost or leaked,I can sign information(subkey's publickey + "destroy subkey") with my mainkey
and  broadcast it to p2pnet.Attacker maybe already see my history mail,but he cannot do anything more
when I destroyed my old subkey and active a new subkey.
Most important thing is,I don't have to destroy my kehotee ID,Specifically my founder ID.And Attacker cannot
destroy my kehotee ID with only subkey too.

mainkey->destroy subkey
mainkey->destroy ID

4,My keyhotee ID is totally safe now.
We can make more function with mainkey and subkey.

:-)
« Last Edit: December 07, 2013, 08:28:50 am by logxing »
BTS Account:logxing

Offline lib

  • Sr. Member
  • ****
  • Posts: 243
  • liberty
    • View Profile
wow

Explain the nature of your 'wow'?

It seems some company names like google/apple/ebay were registered here just now. Are they robots?
Sorry to out of thread :D
Forum Donation: PforumPLfVQXTi4QpQqKwoChXHkoHcxGuA
Personal Address: PakhuBkqTu4oTHJ4ZffvzVwCGCMfuqazgm

Offline bytemaster

For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.


Offline HackFisher

  • Hero Member
  • *****
  • Posts: 883
    • View Profile
Is the password some fixed password using md5 stored on disk like Linux OS, or some Encrypt Interface could be customized by users?

I think it may be possible to add 2-factor auth if there is such encrypt interface, ex. using SMS or Google Authenticator. I still have no idea whether it is meaningless to do this.

For the bottom line and OS level, I know there are a lot of software with root/administrator authority to the OS, can hook to api call, and capture datas, including some anti-virus softwares. I don't whether we could to do something to avoid this?

Keyhotee asks you for your password when you start the program and will keep your private key in memory only.  On disk it is always encrypted.

In order to process incoming messages your private key needs to be 'live' at all times.  There is no way around that. 

With the wallet system you only need your private key for sending money.

Bottom line, you are relying on the physical security of your computer and OS while Keyhotee is open.    Any bright ideas on how to improve that?

Authentication and Encryption are two different things.  Authentication such as google authenticator can answer a 'yes' | 'no' question but does not protect a private key.  So we could add Google Authenticator at launch but an attacker who got a copy of the wallet on your disk would still be searching for the password/key that is protecting it.

OK, I got it, thanks.
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline bytemaster

Is the password some fixed password using md5 stored on disk like Linux OS, or some Encrypt Interface could be customized by users?

I think it may be possible to add 2-factor auth if there is such encrypt interface, ex. using SMS or Google Authenticator. I still have no idea whether it is meaningless to do this.

For the bottom line and OS level, I know there are a lot of software with root/administrator authority to the OS, can hook to api call, and capture datas, including some anti-virus softwares. I don't whether we could to do something to avoid this?

Keyhotee asks you for your password when you start the program and will keep your private key in memory only.  On disk it is always encrypted.

In order to process incoming messages your private key needs to be 'live' at all times.  There is no way around that. 

With the wallet system you only need your private key for sending money.

Bottom line, you are relying on the physical security of your computer and OS while Keyhotee is open.    Any bright ideas on how to improve that?

Authentication and Encryption are two different things.  Authentication such as google authenticator can answer a 'yes' | 'no' question but does not protect a private key.  So we could add Google Authenticator at launch but an attacker who got a copy of the wallet on your disk would still be searching for the password/key that is protecting it. 

For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.