[ANN] USSC Crypto-P2P-Server | Decentralized P2P Exchange & Application

[usscfounder]

What do you think about something like this? SPKI/SDSI:

http://csrc.nist.gov/groups/ST/key_mgmt/documents/Sept2012_Presentations/LAMBERT_CKMW2012.pdf


I am looking at this because it doesn't use a CA plus there are some other customizations I can make.

From Wikipedia:

SPKI/SDSI does not define a role for a commercial Certificate Authority (CA). In fact, one premise behind SPKI is that a commercial CA serves no useful purpose.[1] As a result of that, SPKI/SDSI is deployed primarily in closed solutions and in demonstration projects of academic interest. Another side-effect of this design element is that it is difficult to monetize SPKI/SDSI by itself. It can be a component of some other product, but there is no business case for developing SPKI/SDSI tools and services except as part of some other product.

http://en.wikipedia.org/wiki/SPKI

http://tools.ietf.org/html/rfc2692

http://tools.ietf.org/html/rfc2693

[usscfounder]

A solution I am looking at is a type of automated hierarchical key generation. I want to remove the human element as much as possible. I will give the "mayor" of the city power over they top level nodes. But everything else from there would be automated by the nodes according to hierarchy.  I will explain later.

[usscfounder]

Another feature I like about SDSI:

http://tools.ietf.org/html/rfc2693

2.8 Fully Qualified SDSI Names


   SDSI local names are of great value to their definer.  Each local
   name maps to one or more public keys and therefore to the
   corresponding keyholder(s).  Through SDSI's name chaining, these
   local names become useful potentially to the whole world.  [See
   section 2.6.2 for an example of SDSI name chaining.]

   To a computer system making use of these names, the name string is
   not enough.  One must identify the name space in which that byte
   string is defined.  That name space can be identified globally by a
   public key.

   It is SDSI 1.0 convention, preserved in SPKI, that if a (local) SDSI
   name occurs within a certificate, then the public key of the issuer
   is the identifier of the name space in which that name is defined.






Ellison, et al.               Experimental                     [Page 11]

 
RFC 2693                SPKI Certificate Theory           September 1999


   However, if a SDSI name is ever to occur outside of a certificate,
   the name space within which it is defined must be identified.  This
   gives rise to the Fully Qualified SDSI Name.  That name is a public
   key followed by one or more names relative to that key.  If there are
   two or more names, then the string of names is a SDSI name chain.
   For example,

        (name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) jim therese)

   is a fully qualified SDSI name, using the SHA-1 hash of a public key
   as the global identifier defining the name space and anchoring this
   name string.

[usscfounder]

Here is another feature I like about SDSI:

http://tools.ietf.org/html/rfc2693

4. Delegation

   One of the powers of an authorization certificate is the ability to
   delegate authorizations from one person to another without bothering
   the owner of the resource(s) involved.  One might issue a simple
   permission (e.g., to read some file) or issue the permission to
   delegate that permission further.

   Two issues arose as we considered delegation: the desire to limit
   depth of delegation and the question of separating delegators from
   those who can exercise the delegated permission.

What do you think?  Is SPKI/SDSI something that can fit in this p2p design?

Give me some feedback.

[usscfounder]

Give me some time. I am going to think about this for a bit. Check back tomorrow.

[usscfounder]

I GOT IT!

Ok. Where do I start?

Last night I was thinking and meditation about how to secure the whole system to answer Michael question in the previous posts.

I really could not come up with a good way to secure the system. So I did what I did the night I came up with the BTA solution.

I prayed.

Afterward the answers came. Three answers actually.

The first answer was:

You don't understand the question. Look at it again

Ok. So I tried to remember Michaels post:

You use certificates and keys to secure the server nodes. A rogue node could not transact with any of the P2P server nodes.

But a legitimate node could disrupt transactions. What differentiates a rogue node from a "real" node?

I'm just saying I'd like to see you write something specific about the security of the exchange system you are proposing.

-Michael

Then I understood what he was actually asking. So I am going to rephrase the question:

What do you do to mitigate the worst case scenario?

What is the worst case scenario? I will tell you what it is.

A trusted sysadmin who has gone rogue.

Let's say that Gavin or Coblee's best friend and most trusted sysadmin in the whole p2p exchange network who's name is Charles decides:

Hey, I am tired of making peanuts for salary. I got a quarter million dollars in BTC in the wallet banks of my server. I think I will just empty them and then go to Cancun.

How do you stop a sysadmin who has gone rogue and has physical access to a server?

The truth is you cant.

and that when the second answer came to me:

Remove the wallet.dat files.

Remove the wallet.dat files?  If I remove the wallet.dat files from the server then how do conduct cryptocurrency transactions?

So, I though about it. Then I hit me. Like a ton of bricks.

It was genius. Plus, I could not believe that I had the answer all along. The answer was something I was already doing for my personal security.

Then I realized the answer was to use something that I call a "disposable wallet"

(I AM WRITING THIS AS YOU READ IT...  CLICK REFRESH TO UPDATE THE SCREEN)

[usscfounder]

I got black suits all around me all of a sudden. be back...

[Boxman90]

So... is this a real life soap opera?

[usscfounder]

Oh my Lord I almost had a heart attack. Either the president is in town or they were seriously trying to find me.

Ok. I talked to a security guard. He told me some rich lady with 20 bodyguards just went through. Maybe. But I saw them going from PC to PC looking at the screens. I got the hell outta there.

Ok I am back now.

[btceic]

How about making this into an easy to install pre-configured linux/bsd distro?

Users would be able to download the ISO and run it on just about any machine.

From my near zero knowledge of linux and from what I recall with speaking about it to colleagues over the years a variant of NETBSD is the most hardened out of the box no?

[usscfounder]

Disposable Wallet Method:

Just what is a "disposable wallet"? Its not just a wallet you use then throw away. Its way more complex than that.

A "Disposable wallet" is a one-time use wallet whose contents are in an un-redeemed state in the blockchain. Once the private key is imported into the Bitcoin client and a transaction has occured the wallet is then discarded. Any coins left over from the transaction are sent to a new "Disposable wallet" and those coins also remain in a non-redeemed state in the blockchain as well.

Disposable wallets are brain wallets that you generate using something like bitaddress.org.

If you click on the brain wallet tab of the site and enter a passphrase:

maryhadalittlelamb

the javscript will output this:

Bitcoin Address: 1Fcf6bCJWt2UGkK9fnTWnynY9dMcoA2v3v

Private Key (Wallet Import Format): 5KgCWZGaSqAFv5Fv74thJR4Gzv4KFPX13q4WidDmELnYNHoqGNf

After the wallet is generated. You can immediately send money to that address:

Bitcoin Address: 1Fcf6bCJWt2UGkK9fnTWnynY9dMcoA2v3v

If you send money to that address and do not use or import the private key into any bitcoin client then the transaction will be added to the blockchain and the coins will have a status of NOT-REDEEMED.

As long as you do not import the private key in to any Bitcoin client the status will not change.

A "Disposable wallet" is a one-time use wallet whose contents are in an un-redeemed state in the blockchain. Once the private key is imported into the Bitcoin client and a transaction has occured the wallet is then discarded. Any coins left over from the transaction are sent to a new "Disposable wallet" and those coins also remain in a non-redeemed state in the blockchain as well.

How does that help secure the p2p exchange servers from rogue admins?

The answer is simple:

After generating the private key, you split the key into multiple parts and then store them on multiple servers in the p2p network.

With this scenario, there are no wallet.dat files even stored on the server. All that is stored are partial private keys.

If a rogue admin tries to access the wallet banks all he will be able to retrieve are partial private keys.




So how do you conduct a transaction?  

With something I call a "wallet-virtual-server" or "transaction-server" or "wallet-bot".

I will tell you about "wallet-bots" in the next post.



 




(I AM WRITING THIS WHILE YOU READ IT... CLICK REFRESH TO UPDATE THIS POST.)

[usscfounder]

How about making this into an easy to install pre-configured linux/bsd distro?

Users would be able to download the ISO and run it on just about any machine.

From my near zero knowledge of linux and from what I recall with speaking about it to colleagues over the years a variant of NETBSD is the most hardened out of the box no?

The point I was making earlier when I said that I could make the whole system with just Linux tools was that; if I could do it, then it should be easier for a software developer to do it.

If you know C, C++, or php you can do it a lot better than I can. You can make it more secure as well. I was just demonstrating the ease in which it could be deployed.

Perhaps a combination of Linux and Code. That would be far more secure.

You don't have to use a SQL database. Use a flat-file dB or anything you want.

[usscfounder]

All the best with your project.

Thank you. I appreciate all of the support I can get.

[usscfounder]

(MORE LATER TODAY)

[usscfounder]

Disposable wallet method can be further secured using the following means:

1. Add a TTL (Time To Live) to the disposable wallet. Whether there is a pending transaction or not, set a TTL on the disposable wallet. This way a rogue admin would only have a limited time to try an attack to collect all of the partial key pieces from the servers in the p2p network.

2. Because there are replicated virtual servers keep more than one online. I know I said earlier to keep one virtual server online and the replicated copies offline. But now I have changed my configuration and design. Keep more than three virtual servers online at a time. Split the partial keys up between the online copies, offline copies, and other semi-offline virtual servers that are not linked to that particular virtual server. for example:

NY-p2p-Server
home-virtual-server-002......online......wallet-key-home-virtual-server-002-bank-001-wallet-004.dat-segment-A-XXXXXX-A-segment-end
home-virtual-server-005......offline......wallet-key-home-virtual-server-005-bank-005-wallet-002.dat-segment-G-XXXXXX-G-segment-end
home-virtual-server-007......offline-monitored......wallet-key-home-virtual-server-003-bank-001-wallet-001.dat-segment-M-XXXXXX-M-segment-end
home-virtual-server-009......online......wallet-key-virtual-server-009-bank-003-wallet-003.dat-segment-P-XXXXXX-P-segment-end

This way a rogue admin would have to hunt the keys down outside of his home-virtual-server groups. The final key he may need may be on a home-virtual-server that he doesn't even know exists on a physical server on the other side of the globe.


3. Rotate newly generated disposable wallet partial keys among the home-virtual-servers.

4. Make sure each generated key is large enough to be split into 25 parts. Split then label each part from A through Y or B through Z.

5. NEVER KEEP MORE THAN $1000 IN ANY WHOLE DISPOSABLE WALLET.  I will explain why later when I explain about wallet-servers or wallet-bots. I will also introduce you to another wallet called an insurance-wallet.

6. Set hierarchies for the wallet-bots with most handling transactions of less than $100 USD.  Higher more secure wallet-bots from more trusted admins (with higher insurance fees) can handle larger amounts. Again never allow any single wallet-bot to handle more than $1000 USD. Period.

[usscfounder]

Wallet-virtual-servers - AKA wallet-bots

A wallet-virtual-server just has one purpose. That purpose is to:
 
1. To retrieve the wallet private key segments, assemble them, then import the whole private key into the Bitcoin/Litecoin client.
2. Conduct the transaction.
3. Generate a new disposable wallet.
4. Transfer any leftover change from the previous transaction to the new disposable wallet address (This will be an non-redeemed transaction in the blockchain).
6. Discard the old disposable wallet.
5. Redistribute the new disposable wallet private key segments among the home-virtual-servers in the p2p network.
6. wipe memory / reboot / whatever is necessary to forget the newly generated key.

Now wallet-bots have rules:

1. Wallet-bots cannot store any information.
2. Wallet-bots cannot retrieve key segments on its own.
3. Wallet-bots cannot retrieve the same key segments that it has disbursed to the p2p network.
4. Wallet-bots are designed to work in groups. A $25,000 USD transfer transaction would require 25 wallet-bots with each bot handling one transaction of $1000 USD.

Note: A rogue wallet-bot can be mitigated by setting a TTL (Time To Live) on the disposable wallet. This is set by the home-virtual-servers that hold the private key segments. When the TTL is expired a different wallet-bot will be used to generate a new address/key and transfer the holdings to the new wallet address; then reallocating the segments to different servers on the p2p network.  

If a rogue bot did manage to steal coins from the network then the p2p network would immediately revoke the keys of the bot, identify the owner/admin of the bot, boot the bot from the p2p network, and the loss would be no more than $1000 USD.

An insurance bot would then activate and complete/replace the transaction of $1000 USD. The funds would come from insurance fees charged to the owners of the servers on the p2p network.

It is best to charge insurance fees to the admins on the p2p network. The admins would recoup the cost by charging transaction fees for the use of their server.  

If an admin's server was used in any transaction on the p2p network, the admins could charge a transaction fee to the users involved in the transaction.  This also gives admins incentive to be honest in service operations.

[usscfounder]

Tomorrow I will show how home-virtual-servers can use a consensus to call forth a wallet-bot to perform a transaction.

Thanks for everyone's support.

[usscfounder]

If you are reading this or printing this out then you might want to re-read or re-print this thread. I have made changes to the configuration and security practices. Most of the changes are on from the Disposable Wallet Section.


ALT-COIN SECURITY

USE WORTHLESS ALT COINS TO DO TRANSACTION VERIFICATION BETWEEN NODES.

All of these new alt coins being created everyday are not necessarily a bad thing. Crypto-coins and their corresponding blockchains can be used for other things besides money. Like securing transactions between P2P nodes. You can use worthless alt coins as transaction verifiers throughout the entire p2p network; and its more secure than using CA certs, pre-shared keys, or other more complicated security setups.

For high security, don't use other alt coins. Make your own customized alt coin for the same purpose. You don't have to worry about double spend attacks because you are only using it for the purpose of securing transactions for the p2p network and you are the only one with access to the coin. Make a coin that is fast and can be mined easily. Afterward, pre-mine it to the hard-limit with enough coins to support the entire network. You wont have to worry about it retaining a monetary value because its pre-mined. Don't give any coins out to anyone except server admins. It shows the users on the exchange that a server admin is validated because no one should have the coins except for server admins.


The good thing about alt-coin security is that no one will have your coin except you. As long as none of the admins don't send their coins to other people. If they do you can find out by doing an blockchain analysis. If no one has your coins except for you then that makes it much harder for a hacker to compromise the p2p network integrity.


Security-Coin Validation
Use the blockchain to verify where the security-coins came from. If a server node sent you security-coins from a wallet address of ABCDEFG1234567 to validate a specific transaction you can verify where the security-coins came from by doing a blockchain analysis. The analysis will show where the security-coins came from. If the security-coins came from an address that you do not know or is not listed in the security list you know not to perform the said transaction. It that simple. No ACLs, no certs, no keys, just alt-security-coins.

High Level Security-Coins
For sensitive servers such as high level wallet-bots use a different security-coin than that which is used by the rest of the network. Only give it out to server admins that are high level. This provides an additional layer of security within the p2p network.

Keep Track Of Every Coin
The head of the p2p network can disburse security-coins to the server admins for transaction verifications and tolls on the network.  As the security-coins travel from the server admins to other nodes, you can make nodes to collect the security-coins and bring them back to you. A security-coin audit can show if any security-coins were lost and where they went and who lost them. This provides better security than other methods; in addition, if a server admin and his nodes are booted or fired from the p2p network you can blacklist his wallet address or refuse to give him more security-coins to perform transactions and pay tolls on the network.

Transaction Tolls
Transaction Tolls provide a way to control and maintain the p2p network. Certain nodes require certain security-coins and a specific amount. For example, a high level transaction involving a large sum of money might require a larger amount of security-coins before the transaction will take place. Only admins with that amount of security-coins will be able to perform the said transaction.

Security-Coin Dual Wallet Application
I recommend coding a dual-wallet application for the wallet-bots. Code the wallet application so that the Bitcoin/Litecoin wallet will not send cryptocurrency to anyone unless there is a sufficient amount of security-coins to perform the said transaction. You can hard code the security-coin amounts based on how much cryptocurrency is sent. This would make it much harder for a hacker to get the bot to send coins to an illegal wallet address.

 

[usscfounder]

Hey, can I get some feedback.  What do you think about alt-security-coins?  What should I call them?

1. Secoins
2.Seccoins
3. Sec-coins
4. s-coins
5.

[btceic]

SecCoin
AnonCoin