Topic: Unbreakable protection in dire need of debunking (Bitcoin bounty) (Read 658 times)

Very excited to announce the release of our first public tech whitepaper!

I placed the link in the first original post above - so give it a spin.
This paper is targeted at technical audience at varied levels - from a proficient user to cryptography researcher.
Hopefully, this should complete the pack of all the information needed for anyone to give the H4X a run for our money.

Looking forward to comments, feedback, thoughts, criticism, trolling... ahm, scratch that. No trolling.

The source code is out!

And not only it's out, we've worked extra hard to make sure anyone can easily stage the whole environment locally and get this system compiled and running in no time.
That's my excuse to why it's taken that long and I'm going to stick by it!

Would be great to get feedback, suggestions, bugs, ideas - or just find out this helped you snatch our bitcoin away.

I've added the github address to the original post above, together with our telegram channel if anyone's up for a chat.

An updated whitepaper is going through its last review cycle and will be out shortly too.

Stop wasting time. Study Bitcoin more assiduously. You'll find you bend to it, not it to you.
Here's the thread archived up to the previous post. https://archive.is/ZtaCx

Not sure what's the proper etiquette to dealing with trolls here, but out of respect to this forum, I'll try and rephrase the sarcastic statements into a constructive conversation:

That's a very good question. I believe there's no consensus on that - not even in this forum. There's a lot of research already demonstrating that there's a strong belief that bitcoin will hit mainstream adoption, but none that I could find on whether it should. From many discussions on this topic, I found both the most extreme bitcoin's anti-establishment advocates and the ideology-agnostics have interest in seeing an increase in value, liquidity, volume, stability and utility of the coin. Being "fundamentally humanitarian" movement suggests it addresses... all humans? But I can see why some will want to keep it away from mainstream.

I'd like to thank you for pointing that out. This is a misunderstanding I take full responsibility for causing as I completely neglected to clarify: the entire h4x exercise is a pure proof-of-concept environment aimed at showcasing the new concept and engaging with the community to scrutinize and perfect it. The Tide Protocol itself is more than a year away from going live. Once live, anyone will be able to host and run an ORK node anywhere (public cloud or not) and join the decentralized network. The current 50 nodes have been deployed by us on the 3 most common public clouds to allow for the easiest targeting. We're still looking into ways to allow as much public access into those nodes as we can.
I'll add that clarification on my original post now.

As I see it, those are not mutually exclusive nor contradicting concepts. If anything, giving "the people" that level of accountability over a scarce (dare I say, financial) asset is a step forward for humanity. The Tide Protocol is all about personal gain for personal accountability. Mainstream or not, I don't see any individual or community protected against that fallibility - so why make it a barrier? No current technology, as complex and inconvenient as may be, can offer that protection. Not even airgap segregation - as proven with the stuxnet attack (https://www.f5.com/labs/articles/cisotociso/attacking-air-gap-segregated-computers, https://www.zdnet.com/article/how-safe-is-your-air-gapped-pc-attackers-can-now-suck-data-out-via-power-lines/). As we see it, what's left is a continuous forward evolution of a different mixture of compromises between security and usability in pursuit of the holy grail of pure trustlessness.

I'm really not sure how to approach that question. Neither from a technical nor philosophical aspects. I can only imagine it's an emotional subject - for which I'd like to categorically apologise if this discussion thread, or even the entire Tide notion, offends anyone. I'm not being sarcastic, condescending or funny here. I can truly appreciate how this can be construed by some as almost blasphemous - and it is not the intention here. As engineers, it is with the purest of intentions we hope to improve or better current technologies - even for those perceived to be perfect as is. To those offended, unless they can find ways to humour themselves by contributing to our cause, I can only invite you to ignore this thread in the future.

You assumed it right, the nodes on those cloud provider are temporary.  It's the fastest way to test the concept.  Once live, those nodes can be  deployed by anyone.


Going mainsteam isn't just for bitcoin but its crypto/blockchain in general.   It's a technology that will be for the masses. It isn't now but it will be.  Baby steps

Meh no you're right it's probably just a few who see the ubiquity of 'crypto-wallets', 'websites' and 'global mainstream adoption' all as the wrong directions for research.

I'm just being picky, but tell us more about the 'decentralised Tide network' that has '50 nodes' parked on 3 State-controlled clouds.
Presumably just temporary. Because as you know there is only one blockchain with any security whatsoever.
Do you see it speeding up or something?

True. How does this reconcile with seeing bitcoin as something for the mainstream?
How does it reconcile with users placing their trust/money in any team other than the one now successfully securing all the money?

Awesome questions, dude/t. Keep 'em coming!

I would hope so, yes. Proving this claim would be an outstanding success of this exercise because we want to make sure we aren't introducing additional weaknesses with all ork servers, etc.
Assuming it's a given (although yet to be proven), the specifics of the protocol takes the standard security levels of user's password and increases it by several magnitudes of scale - meaning, even your weakest password will pose a tremendous challenge for a hacker using this authentication scheme. We're about to publish a research we did on the exact levels of improvement our scheme introduces to the conventional username/password authentication methods - so you will be able to see the details there. It would be great to get some public scrutiny on that too.

Unfortunately and ultimately, yes. That is a common impediment to any human authentication technology (biometric, MFA, crypto, etc). There's still no cure for the infinite extent of human fallibility.
We definitely not attempting to solve that problem - rather significantly improve on the security and convenience of existing crypto usability.
I'll just leave this here for reference: https://www.reddit.com/r/CryptoCurrency/comments/bokm1t/electrum/

Yes. We have an exponentially-increasing-delay-throttling on failed login attempts on every ORK. We also plan to introduce user notifications at a certain point. We're still contemplating what the best point for that.

Your suggestion invited many long internal debates on the best approach to do that. Again, thanks for that! We're trying to think on the optimal way to implement it in a verifiable way - meaning, in a way we can prove to you (or a hacker) that those simulated logins actually happened/happening. This is posing quite a challenge without exposing the private key. One thing worth noting is, the simulated user will verify the javascript code hasn't changed using the SRI (https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity) signature - so a hacker will have to circumvent that.
Again, this is for when we'll be testing the data-in-transit scenario, still will be happy to discuss more ideas on the best way to run this.

ok, so despite all ork servers, etc, ultimately the security comes down to strength of user's password, correct?   Because with that, the private key becomes assembled (somehow).

So in a real world scenario, phishing attacks, keylogging, etc would apply.   yes?

re brute force attack:  do you limit the number of failed login attempts and/or notify user of such?


I just meant that if you were to simulate user logins/actions in order to make the contest more "real" and dynamic then each time a user creates or updates a record, it could contain the same 1BTC private key (as opposed to my previous suggestion of splitting the 1BTC into lots of pieces, ie divided between users).   no big deal.

First, thanks!

You understand correctly. Mostly. With few minor gaps that will probably change everything  
That's totally our fault, btw. I don't want to keep you waiting for the release of our tech whitepaper - so here's the full explanation:
The BTC is held encrypted in the SQL database - that's correct. The key is held with the user on their device - that's also correct, but incomplete.
Not on the server - well... that's partially correct. Not on the server but on servers.

Let me explain:
The ultimate goal is for the user to be the only one with his key, on his device, being the only one able to encrypt/decrypt and sign.
It would be so easy if we could assume users set up their devices so we can store the key there - but we found we can't. On mass scale, users find wallets (hardware or software) usability to be too complex and restrictive. They don't understand the process of securing private keys or mnemonic phrases and they want to be able to set up the same wallet on multiple devices (desktop, tablet, phone, etc) easily. Using QR codes is great - but still light-years more complicated to the average user than the ease of a username and password or even 2FA.

The Tide Protocol defines 4 kinds of client-side wallets - with a secure device or software wallet being 2 of those options, however for the widest mainstream audience, Tide defines a new type of wallet.
With the Tide Protocol's ubiquitous client, we reconstruct the wallet, with all its preferences and private keys - on the fly, in the desktop browser, all from just the user web authentication. We reconstruct it from a set of decentralized array of nodes (ORKs) that as a collective, have enough information to cater for that process - so you can say that the information required to get the key is on those servers. When you log in using the dummy credentials, that's exactly what's happening.
I know that reconstructing private keys in javascript, in the browser, from publicly accessible servers sounds like a terrible security nightmare - but we've been working on it for quite some time to make it fullrproof* and we believe we have. Or close to it.

You mentioned modifying the javascript on the server side as a likely attack vector for data-in-transit scenario - which may be true, and the Tide Protocol has countermeasures for that too, but that's not the focus of this exercise just yet. We plan to add it later on (I can't wait for it!).

Currently, we look at a data-at-rest scenario with all possible attack vectors on the servers (web, database, ORKs, blockchain, etc) which suggests that if there's any vulnerability on any of the servers in this architecture, someone can definitely exploit it to get the BTC. Possible vectors would be:

• Break the database, get the encrypted records and brute force it
• Break the ORKs - get the user key (CVK)
• Brute force / dictionary attack the username/password

This sounds very interesting. Can you elaborate on that? What did you mean by "every user record modification could contain the private key"?

Are you suggesting no one in the Bitcoin Development & Technical discussion forum is interested in an open-source technology enabling crypto-wallets (bitcoin or any other for that matter) to be as ubiquitous and intuitive as any website?
Do you truly believe that bitcoin will hit global mainstream adoption without efforts like this?

And just in case you missed it, the EOS component here is completely secondary as the underlying blockchain is decoupled from the solution. At this stage, using the live bitcoin network as the underlying trustless repository will simply render this exercise very slow and expensive.

Saying that, I do look to hear from others in this community and take advise if this ISN'T the best place to explore this technology. As I see it, it's the perfect community to drive it.

Move the thread to altcoins please; nobody's interested in EOS or Tide here.

If I understand correctly, the 1BTC private key is stored encrypted inside a SQL database and the encryption key is held by a user on their own device (not on the server).

As such, if an attacker is able to get into the server, even root access, full database dump, etc, they still will not be able to access the private key.

That's a good design, imho.  I wish all companies would do it.

So as far as this competition/bounty goes, I doubt anyone will obtain the 1BTC.

That said, the present scenario does not accurately reflect conditions in a production environment.

In production, you would have user records being created and updated.

In this scenario, if an attacker is able to get into your web server, they should be able to modify javascript sent to the client in such a way that the client sends data unencrypted to server (or another server controlled by attacker) when creating or updating a record.

As such, I would propose that for this test/bounty to actually be useful and meaningful, you should modify the test conditions with simulated users that are regularly creating/updating records that contain valid private keys.   This would probably require splitting the 1BTC into many smaller pieces.

A patient attacker with server access could sit and wait until they have collected some or all of it.


edit: or every user record modification could contain the private key for full 1BTC.  Then a single breach would result in full bounty.

In addition, here's the data workflow design in the form of a swimlane diagram with the following conventions:

• Vendor lane represents the h4x web site
• Consumer lane represents the client side - the desktop/browser process
• ORKs lane represents the Tide decentralized network

This design is, obviously, not a line-by-line low-level-design, but a more abstract depiction of the data and process flow.
Annotation used are common cryptography annotation - but feel free to ask if there's any ambiguity.
No such thing as a stupid question.

Dataflow Diagram:


update: fixed diagram link

As promised, here's the network architecture of this particular system:

• A simple web site set up of a web server, web API service and an SQL database
• The database has the user records - each with its own login/password
• Each user record has encrypted personal data
• One user record holds the live bitcoin wallet private key
• Each user has its own unique key for encryption/decryption
• Security (authentication, encryption and decryption) is done through the Tide network
• The Tide network is deployed across 50 nodes (ORKs)
• ORKs are distributed across the 3 main public clouds: Azure, AWS, Google
• Each ORK is managed and maintained separately with its own unique credentials
• For this environment, the Tide network is using EOS public blockchain

Network architecture diagram:


update: fixed diagram link

Agreed. On the way over the next few days!

We use the Crypto.getRandomValues Cryptography API call which is generally regarded as a cryptographically secure pseudo-random number generator (CSPRNG) (https://lwn.net/Articles/666407/). Relying on the javascript engine (which mostly rely on the OS crypto engine behind it) does suggest certain vulnerability but hardly any more than your average crypto-wallet. In fact, Metamask is using the exact same method (https://metamask.zendesk.com/hc/en-us/articles/360020091432-How-does-MetaMask-Generate-Your-Keys-). We acknowledge the recommendation by W3 to refrain from using that method to generate keys (https://www.w3.org/TR/WebCryptoAPI/#Crypto-method-getRandomValues) but we consider that relevant to only specific key types (RSA, Elliptic Curve, AES, etc) and not to our ElGamal based keys. For reference, OpenPGP also using that exact same function (https://openpgpjs.org/openpgpjs/doc/crypto_random.js.html).

Additional read, if you're interested:
https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getRandomValues
https://bitcointechweekly.com/briefs/vulnerabilities-in-numerous-javascript-cryptographic-libraries/
https://medium.com/@dazcyril/generating-cryptographic-random-state-in-javascript-in-the-browser-c538b3daae50
https://stackoverflow.com/questions/5651789/is-math-random-cryptographically-secure
https://adtmag.com/Blogs/Dev-Watch/2016/01/random-javascript-fix.aspx
https://blog.rplasil.name/2016/10/digging-into-browser-csprng_17.html

It's supposed to and it does. We tested it the whole day today. "Server error" was our poor UX response for "throttling limit reached". This message is now fixed and we also relaxed the threshold quite significantly so unless you intentionally brute forcing it, you would never see it.
Thanks for that!

Is it supposed to let you in with admin/password or not? The API returns "Server error". You have a ton of endpoints that it tries.

I've added dummy login details to the original post to showcase the technology. No bitcoin there, but now you get to experience it.

Just in case this feels too ordinary, here's some of what happens when you log in:

• Initializing javascript wallet (generation of random seed, temp keys, primes, etc)
• Encrypting credentials
• Discovering decentralized authentication nodes
• Sending sharded credentials for authentication
• Interpolating key pair
• Solving database authentication challenge
• Decrypting information
• Re-encrypting data when changed

Detailed schematics to follow...

G'day mates

We've developed this radical, new, trustless privacy-protection solution for sensitive personal data on a global scale – which is great but that's not my point. As part of this, we had to address the painful usability problem of blockchain-based products – all the messing around with crypto-wallets, private key protection, mnemonics, etc. We ended up with a solution that looks and feels like your everyday web experience – but with the kickass security of crypto. We believe addressing the UX problem this way will break one of the biggest mass-adoption barriers of any blockchain-based consumer product. And we've got something even my meemaw can use.

Best part is: the whole damn thing is completely unhackable. Or not… That's what we need help to find out. Oh, did I mention we’re a not-for-profit, open source, community-driven project? When we get this right, it’s a win for all (hence bitcoin dev&tech... etc).

So! We put our money on the line and our balls where our mouth is and placed a shiny little bitcoin behind this protection. Whoever breaks the protection will see the private key – no question asked. Well, it’ll be great if you can tell us how you did it, but you don’t have to.

Many more details to follow (github✔️, designs✔️, whitepaper✔️...), but tell us what you need to have a crack. We’re a small team, so we don’t have it all laid out for you in advance – ask and you shall receive! Except the btc. Don’t ask for the btc. Or the password. Find it yourself, you lazy duck!

BTC1 awaits at http://h4x.tide.org

(Yeah, we ditched the SSL intentionally! We did everything to make it as exposed as possible. Exploit it!)

---------------------------------------------

Update:
To see the system in action, use these dummy credentials:
username = 'admin'
password = 'password'

Update:
Source code: https://github.com/tide-foundation/Tide-h4x-for-Privacy (with complete installation manual)
Telegram: https://t.me/TideFoundation

Update:
Whitepaper: https://tide.org/share/Tide_Tech_WhitePaper_v1.pdf

Update:
A word about the operational environment: this is a pure proof-of-concept environment aimed at showcasing the novel concept and engaging with the community to scrutinize and perfect it. The Tide Protocol itself is more than a year away from going live. Once live, anyone will be able to download, compile, host and run the nodes anywhere (public cloud or not) and join the Tide decentralized network. To clarify even further: this is not the Mainnet environment. Not even a Testnet.