Topic: AI Coin Development Diary - page 6. (Read 49301 times)

I will not be performing remote attestation at the BIOS and kernel level until such time as the project is successful enough to employ a specialist.

TrouSerS FAQ

Rather, my approach is to perform remote attestation at the application level. Peers inspect each other's tamper-evident logs verifying expected good behavior and detecting faults.


The Texai system works as you describe it as each node has an X.509 certificate. The system has a self-signed root certificate and is its own certificate authority. De-centralized Intermediate certificates are used to create the end-entity certificates for the nodes/roles. These intermediate certificates are widely distributed in the system. Each node has a copy of the root certificate, but not its private key.


Note that Bitcoin Core allows TLS and X.509 certificates already for RPC calls and for the new Payment Protocol. Texai does not need certificates for nodes to ensure third-party verification of the association of a public key with either a web domain name nor an operator's real name. The certificate is used to contain and publish the public key and to permit TLS authorization and encryption of the network traffic. Each operator, indeed each communicating role in the network has a unique UUID that is its identity. The certificate guarantees that whoever uses it has the private key in their possession. I believe that each user could hypothetically create a self-signed certificate and the Texai system would still work OK.

When generating x509 version 3 certificates I use RSA with a key length of 3072 bits and SHA256 with RSA as the signature algorithm. This works on Java 1.8 with the high encryption strength policy enabled, and also works to encrypt websocket traffic to Android and IOS clients. As certificate validation is entirely in my control, e.g at both endpoints of a TLS version 1.2 connection and with all the entries of the certificate available, I believe that the Texai network is resistant to Sybil attacks.

Don't you need special hardware to do remote attestation? The common known remote attestation schemes use a central service to certify the hardware.



What about sybil attacks? In satoshi's Bitcoin a single node either has the economic power to lift a 51% attack or it doesn't. It doesn't matter over how many nodes this is distributed. A counter measure to sybil attacks would be to have signed each node by a CA. The other nodes verify this signature and won't allow more than one node with the same identifier. But then again the system is centralized.

Thanks for the search tip. You are awesome CIYAM!

I spent the last 50 minutes watching an informative video on certificate man-in-the-middle attacks that linked in the OP. Fortunately, I can use SSLSniff to attack the network and trace the certificate validation through the Bouncy Castle source code to ensure that this particular attack vector is closed. I already set the X.509 Basic Constraints properly for the root, intermediate and end-user certificates. An additional hurdle for an attacker is that my system has client as well as server certificates, which I will test with the SSLSniff tool. I searched the Docker registry for a container with this already built, but it should be easy given these instructions.

SSLSniff works on a LAN, e.g. public WiFi network. This design somewhat protected by virtue of white-listed IP addresses for known full nodes.

I suppose the best defense against man-in-the-middle attacks is to use the same techniques as does the bitcoin protocol in which transaction messages are signed by the sender with their private key. I can modify the expected node heartbeat messages to include a signed hash of the inbound and outbound traffic which a network operations agent can check for omitted or extraneous messages performed by a man-in-the-middle attacker.

A goal now is to accumulate a suite of attack tools such as SSLSniff, Metasploit, etc., and record TexaiCoin responses to those attacks to back up my claim that a cooperative coin network is as secure , if not more secure, than Satoshi's Bitcoin.

As I have stated the CA system is *flawed* because of *trust* (just search for "ca certificates hacked") to get a start (do I really need to post the links?).

The Finney attack is nothing new and so I don't see why it is relevant especially as you have shown no way to avoid it (apart from relying upon the CA system which is flawed).

Might I beg some more clarification on the X.509 attack surface given the details I provided?


Thanks for your clarification. I will amend my claim accordingly to "double-spending fraud attacks, e.g. BitUndo".

Double-spending

Here is the well known example of the Finney attack which is based upon double spending. To be clear, what I mean by double spending is the issuance of two or more bitcoin transactions such that at the time of issuance each receiver believes the transaction to be good, yet because the longest blockchain will only contain one copy of the transaction, there is the opportunity for fraud. The appearance of this service caused a great deal of consternation on the Bitcoin core developers mail list ...

BitUndo

Bitcoin does not use X.509 for anything important (it was added for merchants and has nothing to do with the core operations).


Your statement about "sometimes allowing double-spends" is *completely false* - please show me 1 example of a *double spend* in the Bitcoin blockchain to back up your claim (and yes I know *you can't because there is no such thing*).

Respectfully, I ask you to elaborate a bit on both your points.

I use the X.509 v3 certificate generation facilities provided by the well known Bouncy Castle Java library. I use the optional high encryption strength encryption policy settings provided by Oracle java. I use a self-signed root certificate that each node receives, and do not check for revocation when verifying certificate paths because in my system the certificate serves to digitally sign messages, to encrypt traffic, and to identify the full node. The subject item in the certificate is a UUID, not a real name to preserve the anonymity of the node's owner yet retain identity to preclude Sybil attacks.

Bitcoin Core already includes X.509 infrastructure for remote procedure calls, therefore that technology has been vetted by them and run in production.


Regarding double spending, I use a single nomadic mint agent that timestamps each accepted transaction and broadcasts it back into the network for archival and verification. That is a so-called single-writer to the canonical blockchain, which prevents double spending. Right?

Regrading the peer review of my May 2013, whitepaper, the Bitcoin developers that I have contacted prefer to see working code and the test suite. All are skeptical that my cooperative ideas solve the distributed consensus problem.

Again - you trust the CA system which has been *proven* to be flawed.

We just have to somehow *trust you*?

Let's see your papers and how they are reviewed before you ask for any funds please.

BTW - this:

-   Does not permit double-spending, whereas Satoshi's Bitcoin sometimes does.

is *wrong* (if you want to be taken seriously then I'd suggest that you remove it).

Peer agents perform remote attestation of each other's behavior. Tamper-evident logs record context, inputs, actions, and outputs, which when replayed by a validating peer, confirm good behavior or detect bad behavior, e.g. a byzantine fault. The research that I referenced in the May whitepaper for this technique gives the math proving overall good behavior with up to 50% of the nodes faulty. In contrast, Satoshi's Bitcoin can be corrupted by a single mining node with 51% of the network hashing power.

In addition to remote attestation of peer behavior, TexaiCoin will include a distributed network operations center equipped with a suite of open source information security tools that will detect intrusion and unauthorized changes to the host operating system and the Docker containers in which TexaiCoin full nodes execute. As funding from block reward permits, TexaiCoin network portals, that connect to wallets and external processors, will be protected against DDoS attacks by a traffic filtering service.

How do you plan to detect bad nodes?

This diagram supersedes the one posted earlier. Note that I do not plan to fork any existing proof-of-work coins, rather I am demonstrating an alternative approach that I hope will one day be adopted by Bitcoin, Litecoin, Dogecoin, Namecoin ect. developers.

TexaiCoin is designed to run within a Docker container on the Linux operating system. If you want to run this but have only Windows or a Mac, then the VirtualBox software environment can be installed to allow Linux to run on your computer.

TexaiCoin

After completing the minimal required changes to my fork of the Bitcoin Core code for creating new blocks with trivial effort, I have been reflecting on how best to demonstrate the technology. Today I am re-branding this thread accordingly as TexaiCoin.


I would like to demonstrate TexaiCoin at the Hashers United Conference in early October. It will not then have all the features needed for a public release but I can say that when released, TexaiCoin will have the same parameters as Bitcoin and will launch with a genesis block and no premine. This coin is to be marketed as a cryptocurrency especially suited for microtransactions and immediate acknowledgement that the accepted transactions will appear in the next block.

Here is an illustration of how a server in the Texai network will be configured with Docker containers that provide isolation between cryptocoin daemons, e.g. bitcoind, and the Texai software agents that control them ...

Here is an organization chart design for the nodes within a particular server in the Texai cognitive architecture. Each node contains roles, which are the software agents that collectively perform the node's mission. Roles, in turn, have skills which are Java objects that provide perception and action behavior. Arrows depict the asynchronous task message passing from superior to subordinate roles. Likewise, perceptions, e.g status reports flow upwards from subordinate to superior.

Each node has the following essential roles ...

• GovernanceRole
• HeartbeatRole
• NodeLifeCycleRole
• NodeLoggerRole

The TopFriendshipNode is the topmost node in this hierarchical control network. It's mission is governance, moreover ensuring that the system is friendly.

The NetworkConfigurationNode contains the NetworkConfigurationRole which performs the node's mission of scheduling the nomadic software agents such as the MintRole.

The NetworkOperationsNode contains the NetworkConfigurationRole which performs the node's mission of network operations management. It contains the BootstrapRole which has the skills to on-board a new server into the Texai network. It contains the RecoveryManagementRole which supervises recovery from a fault. It contains the SoftwareProvisioningManagementRole which supervises software provisioning, e.g. version upgrades.

Cryptocoin operation nodes may contain the following roles ...

• CoinSeedRole - Uses the Texai encrypted torrent library to seed new servers with the cryptocoin's blockchain
• BlockchainArchiveRole - replicates the canonical blockchain with new blocks created by the nomadic mint agent
• MintRole - The nomadic cryptocoin minting agent
• RewardAllocationRole - The nomadic cryptocoin block reward allocation agent
• FinancialAccountingAndControlRole - The nomadic agent which balances the blockchain against processed transactions, and provides traffic statistics to network operations
• PrimaryAuditRole - the nomadic agent which has primary responsibility for verifying the behavior of the MintRole and RewardAllocationRole
• SecondaryAuditRole - has secondary audit responsibility
• SoftwareProvisioningRole - performs software provisioning for a particular cryptocoin's Docker container
• RecoveryRole - has the responsibility for a particular cryptocoin's recovery from a fault
• CoinPortalRole - has the responsibility of public communication with a cyptocoin's native protocol to client wallets and transaction processors.
  

The TorRelayNode contains the TorRelayRole which has the simple skill of running a Tor relay instance that encrypts and obfuscates network traffic for those cryptocoin clients that wish additional anonymity by using Tor.

I completed modest modifications to Bitcoin Core that allow the mining of a new block with no effort. The source code branch is named no-pow-mods on my fork of the bitcoin repository at GitHub. My code is here.

The new bitcoin configuration option is added to .bitcoin/bitcoin.conf, where the parameter is the height of the blockchain at the moment of the fork...


The command on Linux to create a new block and then return is ...


And here is the block reward added to my test wallet ...



Next step is to write a simple Java software agent to send the generate command to the running bitcoin-qt instance every 10 minutes.

I claim my cooperative system is trustless in the sense that the source code is open source for inspection, and what few human agents, e.g. developers, network managers, etc., are subject to at least dual control.

The self-signed root X.509 certificate is public except for the private key. Even if the root private key were made public after the issuance of a fixed number of intermediate certificates, I do not see the vulnerability. TLS/SSL traffic is encoded by the end-user (software agent,  not bitcoin user) certificates. Outbound messages from a node are digitally signed using the assigned certificates held by software agent roles hosted by that node.

The chain of trust flows from the root certificate through the intermediate certificate to the end user certificate. The validating endpoint has its own copy of the root certificate which it obtained upon being on-boarded into the network. Sybil attacks, I believe, cannot be accomplished, because both endpoints know each other's certificates in a system in which persistent network connections are managed by distributed, redundant network operation centers.

Sure - you are asking for *trust* so I am just making sure that people are aware of that (if they want to trust your system then that is up to them).

I could mention about my own years of experience (in financial and other fields) but I think it is irrelevant to the discussion.

Not to quibble, but in my two decades of enterprise billing and payment system experience, I found that reasonable data security practices prevented loss of customer funds. I believe a public trial of cooperative Bitcoin will demonstrate its resistance to hacking - or not.

It won't help - the corruption (or cheating) is not possible to stop with any system (that is why Bitcoin is what it is).

Basically you'd need another Bitcoin blockchain to stop any fault with your CA system which means you are back at square one.