REMME – A blockchain-based protocol for issuing X.509 client certificates | Hacker News Reader

REMME – A blockchain-based protocol for issuing X.509 client certificates

github.com

33 pointsfedotovcorp40 comments

I spent 5 minutes trying to find out what and how this is supposed to work and all I figured out is that there's some kind of Hyperledger Sawtooth blockchain (whatever that is). No idea how that's helping with authentication for a web service.

Edit: I now skimmed through the linked architecture overview video and I don't see how that makes authentication any more secure: They seem to build a "distributed storage/management facility" for public keys from what I get from the video. How private keys are handled is nowhere mentioned. So I don't see how that makes anything more secure. From what I understand it might only make the verification part more distributed.

But its got what plants crave; block chain.

REMME WebAuth solution uses one of the better ways of authentication through X.509 client certificates. Certificate-based authentication allows users to securely access a server by exchanging a digital certificate instead of a username and password. This means the client is not sending a username or password to the server which helps in preventing phishing, keystroke logging and man-in-the-middle (MITM) attacks among other common problems with password-based authentication. The certificate hash and status are stored on the REMME Blockchain. Server checks status of the certificate before login on the site/service.

I've read through some of the docs and I'm still struggling to understand the point of the blockchain in this case.

Specifically, what is it offering above, say, self-signed client certificates? From what I've read, you're not adding incontrovertible identity information to the blockchain so what does registering your certificate buy you?

Or put another way, when the server checks your status what do they find out?

REMChain is only part of certificate management infrastructure and also an open source solution. We are working on applications that related to web authentication through OAuth standard, domain validation, KYC, SDK for IoT, but also propose to more broad tech community to search useful approaches for its current functionality. Users pay to the network for the work related with certificate generation, registration, and checks of its validity status during a login process. REMChain makes available to companies to generate its own protected certificates for different uses.

If you want a technology to be widely adopted ("better" auth), and it relies on a niche technology (blockchain), then you need to write your README/elevator pitch/copy/docs in a way that doesn't assume the people using it are experts in the niche technology.

I'm not dumb, but I'm also not a crypto expert and have no desire to become one. I also know next to nothing about the blockchain and have no desire to learn because it's not my field. My day-to-day walking around knowledge is already packed with stuff related to my field and I just don't have the bandwidth to also become a blockchain expert just to roll something out. I suspect most people who would potentially be rolling out software that would use a blockchain-based auth library are in the same boat.

As it stands I have absolutely no idea how this thing works or why I would ever want to use it.

99% of these crypto projects are aimed to scam people who get excited about words and expressions like "decentralised", "proof of work", "proof of stake", "unbreakable", "foolproof", "fault tolerant consensus"

As it the empty meaningless words this still can happen:

"Ethereum Classic (ETC) Hit by Double-Spend Attack Worth $1.1 Million"

The entire goal of many blockchain projects is to add as many middlemen as possible to skim fees.

You can start with the use of available libraries. You can read about them here https://docs.remme.io/. There are some examples for the beginning that are presented in the description.

We understand your pain related to difficulties to get started with blockchain protocols. One of our goals actually makes it as easy as possible to interact with. Unfortunately, the time that we invest in such adaptation isn't enough, but we have tight terms for our roadmap realization.

Most companies are unable/unwilling to implement U2F. What are the hopes they adopt "a blockchain-based protocol used for issuing and management of X.509 client certificates"?

Many changes occur only after the painful experience experienced by the company. The first ones to implement cybersecurity solutions are cautious and prudent, who do not want to find themselves in a situation where a cyber attack will erode confidence in them.

I don't see why trusting whoever has the most hashing power at any given minute is and advantage.

What are your concerns about the safety of this technology?

I can't find anything concrete about the consensus protocol, can you help?

From what I've found out, to add a block the following happens:

A set of 10 masternodes are randomly selected from the pool of masternodes. The probability of selection is somehow weighted by the node's reputation. Q. How do the masternodes agree on that random selection?

Once 10 are selected, each creates a block and shares it with the other 9. One is selected. Q. How do they agree on that one?

The winner gets a reward, adds the block and then the process is repeated. This seems reasonable.

Have I got this right? If so, it strikes me that the strength of the protocol is in the answer to the first question (not sure why there are 2 stages, why not just pick 1?).

Yes, it is right. You can read more about the concept of consensus here: https://medium.com/remme/proof-of-service-consensus-algorith... It is still under development, hope I can share tech docs about its implementation soon. 2 stages are important for raising the speed of certificate generation that is critical for that sphere.

Quoting remme.io:

> No more passwords — no more break-ins. REMME implements unbreakable, foolproof user authentication to protect your users, employees, and company’s data from cyber attacks.

This is laughable. Nothing is unbreakable. This is using a blockchain so I'd be willing to bet that it's vulnerable to the 51% attack.

This account's post history is also suspicious. They only post articles and links to this project, and do not have any comments (no community engagement).

Of course, there are no solutions that will 100% prevent cyber attacks. The task is to increase the cost of such an attempt when efforts aren't worth the result. In a distributed PKI, it is not possible to access all accounts through a server attack, and it is also possible to dynamically and transparently track all changes in accounts.

Nor will this stop phishing of users handing over their private keys :D

Why does user need to hand over its private key? It obviously breaks the security policy.

Related https://danubetech.com/download/dpki.pdf: possibly interesting at the DNS, CA level. I'm struggling to see how this applies to user passwords though. Wouldn't users still need some form of "password".

You are right. There are a lot such ideas of implementations for DNS, CA level etc. For authentication, there are also field to try it, but of course, blockchain isn't a solution that would fit everywhere.

So Duo without requiring a first password? Where's the value in making something like this distributed?

You can leak out metadata to 3rd parties so the hacker know who has access to what, no due diligence needed anymore.

It depends on how you estimate CA vulnerability and how much your organization ready to trust it. There are enough cases when important auth info was leaked.

TLDR: Blockchain-based distributed PKI.

Does it come with its own 51% exploit?

Yes, it's a product, monetized by yet another crypto-coin: https://remme.io/

So...basically just public/private key authentication?

The answer about the auth process with current protocol was written above.

pity it's blockchain based

It's unclear to me why you would want a distributed PKI to authenticate a centralized app. Or maybe it's only for dapps?

In no particular order, there are a number of blockchain PKI (and DNS (!)) proposals and proofs of concept.

"CertLedger: A New PKI Model with Certificate Transparency Based on Blockchain" (2018) https://arxiv.org/pdf/1806.03914 https://scholar.google.com/scholar?q=related:LF9PMeqNOLsJ:sc...

"TABLE 1: Security comparison of Log Based Approaches to Certificate Management" (p.12) lists a number of criteria for blockchain-based PKI implementations:

- Resilient to split-world/MITM attack

- Provides revocation transparency

- Eliminates client certificate validation process

- Eliminates trusted key management

- Preserves client privacy

- Require external auditing

- Monitoring promptness

... These papers also clarify why a highly-replicated decentralized trustless datastore — such as a blockchain — is advantageous for PKI. WoT is not mentioned.

"Blockchain-based Certificate Transparency and Revocation Transparency" (2018) https://fc18.ifca.ai/bitcoin/papers/bitcoin18-final29.pdf

https://scholar.google.com/scholar?q=related:oEsKmJvdn-MJ:sc...

Who can update and revoke which records in a permissioned blockchain (or a plain old database, for that matter)?

Letsencrypt has a model for proving domain control with ACME; which AFAIU depends upon DNS, too.

It is necessary to consider in the framework of a specific case, but REMME WebAuth is just an example of how to use dPKI with a centralized application. Here you can see the demo: https://webauth-testnet.remme.io/register

You mean, just to have it painfully slow, use obscene amount of energy and be vulnerable of 50%+ attacks? Yeah it is great. Not. :)

Blockchain doesn't have to use PoW, which uses a lot of energy

Current blockchain uses Proof-of-Service algorithm that doesn't need a lot of energy but based on stakes and reputation. Here it is the detailed article about it https://medium.com/remme/proof-of-service-consensus-algorith...

>painfully slow

you can send coins securely with Ark in less than 8 seconds

>use obscene amount of energy

not in Ark, or any other DPOS

>be vulnerable of 50%+ attacks

what is merged mining, DPOS, renewable energy? the world may never know.

Sorry I am not up to date with 2019 bullshit bingo, these mean nothing: Ark, DPOS, merged mining

ark is a coin. dpos is an alternative to proof of work. you get paid by holding the coin. merged mining is from 2012, it’s when two coins use the same algorithm so you can mine both at the same time, securing both chains

perhaps you're referring to implementation details of bitcoin?

And Ethereum and all of the guys who use similar solutions.

Reply on news.ycombinator.com