"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.
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
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
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 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.
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.
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.
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"
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.
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.
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.
> 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.
42 comments
[ 3.0 ms ] story [ 75.2 ms ] thread"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.
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.
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.
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?
Does it come with its own 51% exploit?
Yes, it's a product, monetized by yet another crypto-coin: https://remme.io/
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.
As it the empty meaningless words this still can happen:
"Ethereum Classic (ETC) Hit by Double-Spend Attack Worth $1.1 Million"
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?).
> 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).