Quote from: flipperfish on September 14, 2014, 12:17:52 PM

Quote from: SlipperySlope on September 11, 2014, 08:23:49 PM

Quote from: flipperfish on September 05, 2014, 09:52:47 AM

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

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.

How can you detect tampering with logs on remote peers? I mean a peer not controlled by yourself could send you anything as logfile.

I currently also fail to see how remote attestation on application level could work. As far as I know, remote attestation is only reliable, if there is more or less sealed hardware envolved, that acts as a root for a chain of trust up to the application. So the user performing the remote attestation has to trust in the inability of the attestee to change the sealed hardware and employ his own root. Do you have any ressources to point me to, where remote attestation on application level is explained?

Here is the link to the academic reference used in my white paper: Remote Attestation on Program Execution . Essentially, the idea is to embed digital signatures of the log's hash to that point by attesting remote peers into a given peer's own log. The researchers call this technique entanglement, but I understood it more readily as peer-notarized logs that prove whether or not a particular log has been tampered with.

Quote from: flipperfish on September 14, 2014, 12:17:52 PM

Quote from: SlipperySlope on September 11, 2014, 08:23:49 PM

Quote from: flipperfish on September 05, 2014, 09:52:47 AM

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.

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.

But if each user can create his own certificate (more ore less for free), doesn't this open the door for Sybil attacks?

As a result of my rewarding conversation with CIYAM above, I recently decided to have each node operator be their own certificate authority. My scheme does not rely on a chain of trust from a central certificate authority, indeed I want to preserve that part of the Satoshi Social Contract which says there are no trusted third parties in Bitcoin. I need X.509 certificates to identify a peer solely by their published public key, and to encrypt traffic between nodes via TLS 1.2. I do not need a chain of trust to tie a real name and address to the system nor to the certificate holder.

There is a security concept called Trust On First Use (TOFU), which allows peers to record received self-signed certificates and trust them from that point forward. That is a relatively weak method which I plan to eventually augment by providing an easy to use method of emailing peer self-signed certificates from the peer to an archiving Texai software agent before first use. To identify a peer in the Texai network, I would use the certificate, which cannot be forged due to the public/private key math, together with the IP address of the peer and to use encrypted email for out-of-band communication with the peer. For example a peer operator should receive a periodic digitally signed email from the system detailing their fair share of the mining reward paid to their supplied address. This manual oversight by the operator precludes man-in-the-middle attacks that would divert the reward to another address.

Sybil attacks may occur in Satoshi's Bitcoin . . .

Weaknesses

Quote

Sybil attack
An attacker can attempt to fill the network with clients controlled by him, you would then be very likely to connect only to attacker nodes. Although Bitcoin never uses a count of nodes for anything completely isolating a node from the honest network can be helpful in the execution of other attacks.

This state can be exploited in (at least) the following ways:

The attacker can refuse to relay blocks and transactions from everyone, disconnecting you from the network.
The attacker can relay only blocks that he creates, putting you on a separate network. You're then open to double-spending attacks.
If you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute a double-spending attack.
Low-latency encryption/anonymization of Bitcoin's transmissions (With Tor, JAP, etc.) can be defeated relatively easy with a timing attack if you're connected to several of the attacker's nodes and the attacker is watching your transmissions at your ISP.
Bitcoin makes these attacks more difficult by only making an outbound connection to one IP address per /16 (x.y.0.0). Incoming connections are unlimited and unregulated, but this is generally only a problem in the anonymity case, where you're probably already unable to accept incoming connections.

Looking for suspiciously low network hash-rates may help prevent the second one.

Full nodes in Satoshi's bitcoin identify themselves only by IP address. In the Texai network, that weak identity is strongly augmented by X.509 certificates. Software agents keep track of the uptime and verified good behavior of the network nodes.

Satoshi's proof-of-work method makes it hard for an attacker to obtain 51% of the hashing power to attack the network. I plan for the occasional voting among Texai peers to be weighted according to respective peer stakes and each such vote shall be paid for by the system in proportion to the stake. Thus an attacker would have to obtain 51% of the aggregate stake, which has been proven to be more expensive for the attacker than obtaining 51% of the hashing power in a proof-of-work coin. To my knowledge, no proof-of-stake coin has been compromised in a 51% attack, in comparison ...

List of Historical 51% Attacks on Altcoins