Bitcoin Forum
May 05, 2024, 09:18:52 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Crypto-physics and coin privacy – the last step to implement Coinjoin tech  (Read 1590 times)
abtus (OP)
Newbie
*
Offline Offline

Activity: 5
Merit: 0


View Profile
August 06, 2014, 02:38:21 PM
Last edit: August 17, 2014, 04:34:49 PM by abtus
 #1

Bitcoin platform privacy has been discussed for years and several Crypto-Math proposals to implement the desirable feature come from great crypto-world minds, many of them amazing, complex and highly elaborated.   Coinjoin technology is one of the most accepted solutions (please see GMaxwell’s original post outlining Coinjoin at https://bitcointalk.org/index.php?topic=279249.0).

The most common issue to implement the Coinjoin technology (and other privacy and POS solutions) is the open space to introduce additional code to generate logs (and get transaction maps or relevant user information) that could compromise the privacy level.  Some alternatives require a block chain fork in order to introduce additional crypto-Math layers, others a complex key management to handle P2P communications, with limited results.  IP address location privacy, DOS attacks, operator’s trust and other issues are also present in some proposals.

Back to some of the earliest forms of cryptography, the solution introduced here is a novelty hardware device to simplify and secure the Crypto-Math Coinjoin implementation.   In general, the design includes two major blocks: a first block to perform all basic interfaces with the system plus the potential to include additional services to the crypto-network, running on a preferable Linux platform; and a second block, executing the related crypto process inside an isolated and high secure environment.  Multi-layer anti-tamper design provides the right balance between the security/privacy level and manufacture cost by exploding physical properties. These properties cannot be cloned or reproduced in real world (at least from the universal public physics knowledge available) to keep the required device’s integrity and security.  It could be named Crypto-Physics as a complement of Crypto-Math.

The system provide IP obfuscation (service packet routing without external services like TOR),  expansion for additional  features, trustworthy and reliable operation by validating device’s integrity and rejecting malicious altered/fake devices on a distributed consensus network (including device delivery) with a simple, innovative and cost-effective open source multiprocessor platform.

The ownership cost of the device will be less than a standard GPU rig, with better ROI (main income operator from transaction fee consolidation. No additional fees for the Coinjoin service).

The main target are Bitcoin and Litecoin users, but not limited to. The device could help accelerate/improve developments like Dark wallet or Sharecoin for Bitcoin, introduce privacy functionality to any coin compatible with the Bitcoin protocol and complement other privacy coins in development.  The device can be configured to provide service to more than one coin at the same time.

The current device design introduces 3 variants:
-   For miners and small investors (home/office use, paper printer/QR screen display/USB, for personal ATM service)
-   For small merchants (NFC, QR scanner, paper printer)
-   For pool operators/miner farms,  crypto-coin exchange operators, internet merchants and large volume operators (crypto-coin banks/investment pools)


The cost to successfully execute an attack to a single device is way higher than the ownership cost and will not return any additional benefit than an academic exercise (no risk to lose coins in the regular decentralized service).  The very limited internal resources in the isolated crypto-processors with the open source API interface kill the risk to generate any hidden logs.

The secure properties of the device have been discussed with several specialists and will not be the main topic to discuss in this pre-release announcement.  Crypto-physic properties and anti-tamper technology details will be released with the device launch.  (abtus is a development codename for the device; final release device name will be announced with the security details)
As a preliminary announcement, a bounty equivalent to at least 10 times the device value will be awarded to the first group (or individual ) that will describe a reproducible procedure to hack or compromise the device security (and continue its normal operation) without expend more than 20 times the device value.

1714943932
Hero Member
*
Offline Offline

Posts: 1714943932

View Profile Personal Message (Offline)

Ignore
1714943932
Reply with quote  #2

1714943932
Report to moderator
"This isn't the kind of software where we can leave so many unresolved bugs that we need a tracker for them." -- Satoshi
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
abtus (OP)
Newbie
*
Offline Offline

Activity: 5
Merit: 0


View Profile
August 06, 2014, 02:49:46 PM
Last edit: August 06, 2014, 10:43:03 PM by abtus
 #2

Communication channels

The communication channel between “wallet clients” and abtus nodes are encrypted with the pubkeys of each party with an optional and recommended middle abtus node to protect the user IP address privacy.  It works similar as a VPN with abtus nodes as routers/servers. The encrypt/decrypt process occurs inside the isolate crypto processor unit, running open source software.


Proposed basic operation modes:

There are many variants to implement the Coinjoin technology with the complement benefits of abtus node Crypto-physics. Additional variants could be created with the standard API. Here are some basic forms.
1- Simple Coinjoin implementation.
The user sends the signed inputs and desired outputs, Trust operator create the Coinjoin transaction.  Suitable for well know sites (crypto-currency exchanges), high reputable sites/ operators with external trust layers or collateral.  The abtus node guarantees a private processing with no logs. User IP address, inputs and outputs mapping are not reveled to operator at any time.

2- Regular Coinjoin service in a distributed network, shared signed inputs.
The user rely the inputs signature approval to multiple and different abtus devices.
User creates a transaction with an open output and a shared secret signature. User submits the transaction with incomplete inputs signatures, the desired outputs and denominations to a pre-selected final Coinjoin processor.  The shared secret is defined from a set of “N” abtus nodes (proposal N=6, with minimum t=4 required to expend the input).  “N” Abtus nodes validate the outputs in the Coinjoin transaction for the user and sign individually each input as a request of the final “Active” abtus Coinjoin processor. “N” abtus nodes can be selected by the user randomly.

The “Active” abtus processor node is selected from a deterministic function to produce a distributed processing (and fair balanced income between operators) based on the last hash block group value (almost distributed random) produced by miners.
"N" or "Active" abtus operators can not get information about the transaction mapping or user IP address.



3- Coinjoin + POS + quick payment
Similar to simple Coinjoin implementation but with an additional output to restaurant “hold” coins temporarily. Suitable for public places with a “service time” equivalent or larger than one block creation. (ex. Restaurants).

1- Restaurant operator prints the "welcome" ticket and gives it to diners inside the menu. Diners scan the code and start the two stage Coinjoin transaction with quick payment release. Multiple parties (inputs) are accepted.
2- Abtus node process the first stage of the Coinjoin transaction. Diners order and enjoy the food and service.
3- Restaurant operator prints the "thank you" ticket for final processing. Diners can leave the restaurant immediately without additional wait or make changes to the final Coinjoin processing.


abtus (OP)
Newbie
*
Offline Offline

Activity: 5
Merit: 0


View Profile
August 06, 2014, 03:05:44 PM
Last edit: August 07, 2014, 07:58:11 PM by abtus
 #3

General abtus overview



Security layers overview (to provide isolated processing and guarantee full privacy execution).

Layer 0: Faraday stainless-steel spherical cage to provide basic physical isolation.
Layer 1: Crypto-physic key storage for anti-tamper and integrity validation
Layer 2: Classic multi-layer mesh enclosure
Layer 3: Crypto-physic operation (physic property that cannot be cloned or reproduced in real world, at least from the universal public physics knowledge available) provide additional support to outer and inner layers. Additional info will be released at device launch.
Layer 4: MCU and critical components manufacturers isolation security layer. additional Info will be released at device launch.
Layer 5: Secure mechanism to trigger MCU self destruction if some of the outer layers fail.
Layer 6: Multi MCU EAL4+ / TGC compliant with secure processing and memory protection.
Layer 7: True hardware random private keys generator




The layer 1 (attached to the internal wall of the Layer 0) has the responsibility to guarantee the first level of device’s integrity. The amount of Crypto-keys stored in this layer is almost infinite from a practical perspective. The crypt-physic keys works as a crypt function; each input produces a different and unique result on each abtus device with very large entropy.

Before delivery to final operator, multiple sections representing a tiny portion of the layer 1 capacity are read and temporarily stored in an isolated media. Read the full layer (a brute force attack) on one device will take over a year, considering the large amount of combinatorial parameters values and reading/processing speed (an intrinsic physical limitation). This information will be used to authenticate the device after final operator delivery and to initiate the start-up. 
Once the device's integrity is validated, the device broadcast their existence in the network and starts accepting requests to send small portions of layer 1 to other abtus nodes with random generated parameters. Further device integrity validation will be performed entirely by the abtus network consensus.

The layer 0 & 1 provide the first barrier to authenticate the device (integrity validation) but is not related with the crypto operation.  The crypto communication keys and the operational keys are generated at the start-up by the true random MCU generator (Layer 7) once the device is fully validated. The keys are stored permanently in a special isolated flash memory only accessible for the encrypt/decrypt processor (ARM secure MCU). The outer secure layers, including the operator or the network does not have access to the isolate keys (physically disconnected from API interface by a secure mechanism provided by the secure MCU).

Any physical intrusion like a micro-hole, deformation, visible and non visible light, excessive heat or radiation, pressure or other common hack techniques will modify the crypto-physic function and invalidate the device for trust operation.  A confirmed intrusion will physically destroy the most internal layer that holds the operational crypto-keys.

Software updates

Because the software interface with the system is open source, anyone can verify and monitor the interaction with the API to access the isolated crypto-physics processor.  The software inside the MCU is open source and has a unique signature to validate their integrity.

Software improvements can be easily updated in the main Linux computer platform. Internal software running inside the MCU will require a more complex mechanism and a full network consensus to accept the new signature (the MCU include an internal software/hardware mechanism for limited updates in the future in a secure and trust way). The internal updates are limited to specific values in time, amount and size.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!