Inferencium/website
1
0
Fork 0
Code Issues Activity

Add table of contents. Indent code to match coding style.

Browse Source
This commit is contained in:
inference 2023-03-14 05:51:05 +00:00
parent 73e07b7258
commit 9ef8c5a8b4
Signed by: inference
SSH Key Fingerprint: SHA256:9Pl0nZ2UJacgm+IeEtLSZ4FOESgP1eKCtRflfPfdX9M
1 changed files with 125 additions and 92 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

217
blog/untrusted_the_issue_with_decentralisation.html
View File

@ -5,7 +5,7 @@
<!-- Copyright 2022-2023 Jake Winters --> <!-- Copyright 2022-2023 Jake Winters -->
<!-- SPDX-License-Identifier: BSD-3-Clause-Clear --> <!-- SPDX-License-Identifier: BSD-3-Clause-Clear -->
<!-- Version: 3.0.0.11 --> <!-- Version: 3.1.0.12 -->
<html> <html>
@ -42,97 +42,130 @@
<p class="update_date">Updated: 2022-10-29 (UTC+00:00)</p> <p class="update_date">Updated: 2022-10-29 (UTC+00:00)</p>
<br> <br>
<h4>Introduction</h4> <!-- Table of contents. -->
<p>A recent trend is seeing people move towards decentralised services and platforms. While this is <h2 id="toc"><a href="#toc" class="h2"
reasonable and I can understand why they are doing such a thing, they are seemingly doing it without >Table of Contents<a/></h2>
thinking about the possible consequences of doing so. The issue with decentralisation is trust; <ul>
there is no way to pin a key to a specific person, to ensure that you are communicating with the <li><a href="#introduction" class="body-link"
same person you are supposed to be communicating with. In this article, I will discuss some of the >Introduction</a></li>
security issues with the decentralised model.</p> <li><a href="#examples" class="body-link"
<br> >Examples</a></li>
<h4>Example: Messaging</h4> <ul>
<p>When it comes to messaging your contacts on a centralised platform, such as Twitter or Facebook, <li><a href="#examples-messaging" class="body-link"
the keys are pinned to that user account, using the user's password as the method of identification. >Messaging</a></li>
This approach makes it impossible to log in as a specific user without their password, should it be </ul>
strong enough to not be guessed, whether via personal guessing or exhaustive search. The trust in <li><a href="#solution" class="body-link"
this centralised model is the high security these platforms have. It is extremely unlikely that >Solution</a></li>
anyone other than a government would be able to access the accounts stored on such platforms' <li><a href="#conclusion" class="body-link"
servers, which makes the physical security trusted. As for remote security, should a user's password >Conclusion</a></li>
be compromised, it can typically be reset if the user can prove they are the owner of the account </ul>
via some form of identification; this is where the trust issue of decentralisation occurs.</p> <br>
<br> <br>
<p>In the decentralised model, keys are kept on the users' devices, in their possession. While this <br>
soveriegnty is welcomed, it introduces a critical flaw in the security of communicating with anyone
via a decentralised platform; should a user's device be lost, stolen, or otherwise compromised, <h2 id="introduction"><a href="#introduction" class="h2"
there is no way to know it happened and what the new keys really are, and if the same user generated >Introduction</a></h2>
those keys. There is no centralised point where anyone can go to check if the compromised user has <p>A recent trend is seeing people move towards decentralised services and platforms. While this is
updated their keys, which means there must already have been at least one other secure channel in reasonable and I can understand why they are doing such a thing, they are seemingly doing it without
place before the compromise occurred. Even if there was, the security of endpoint devices, thinking about the possible consequences of doing so. The issue with decentralisation is trust;
especially typical users, is much lower than a well protected corporation's servers, making even there is no way to pin a key to a specific person, to ensure that you are communicating with the
those secure channels questionable to trust. Should all secure channels be compromised, there is same person you are supposed to be communicating with. In this article, I will discuss some of the
literally no way to know if the person you are communicating with is the real person or an imposter; security issues with the decentralised model.</p>
there is no root of trust. This point is fatal; game over. The only way to establish trust again <br>
would be to physically meet and exchange keys.</p> <br>
<br>
<h4>Solution</h4> <h2 id="examples"><a href="#examples" class="h2"
<p>I'll cut to the chase; there isn't a definitive solution. The best way to handle this situation >Examples</a></h2>
is to design your threat model and think about your reasoning for avoiding centralised platforms. Is <h3 id="examples-messaging"><a href="#examples-messaging" class="h3"
it lack of trust of a specific company? Is it the possibility of centralised platforms going >Messaging</a></h3>
offline? Only by thinking logically and tactically can you solve both the issue of centralisation <p>When it comes to messaging your contacts on a centralised platform, such as Twitter or Facebook,
and decentralisation. Often, one size fits all is never the correct approach, nor does it typically the keys are pinned to that user account, using the user's password as the method of identification.
work.</p> This approach makes it impossible to log in as a specific user without their password, should it be
<br> strong enough to not be guessed, whether via personal guessing or exhaustive search. The trust in
<p>In order to avoid the issue of loss of trust due to lack of root of trust, all users' keys must this centralised model is the high security these platforms have. It is extremely unlikely that
be stored in a centralised location where all contacts are able to go to in case of compromise or to anyone other than a government would be able to access the accounts stored on such platforms'
periodically check the state of keys and to see if they have changed. This centralised location servers, which makes the physical security trusted. As for remote security, should a user's password
requires some sort of identification to ensure that the user changing their keys is really the same be compromised, it can typically be reset if the user can prove they are the owner of the account
person who initially signed up for the platform, using a trust-on-first-use (TOFU) model, which via some form of identification; this is where the trust issue of decentralisation occurs.</p>
isn't much different than what today's centralised platforms are already doing; the only difference <br>
is who is controlling the location; trust is still present and required.</p> <p>In the decentralised model, keys are kept on the users' devices, in their possession. While this
<br> soveriegnty is welcomed, it introduces a critical flaw in the security of communicating with anyone
<p>In order to have a root of trust, I have posted my keys to my website, which is protected by via a decentralised platform; should a user's device be lost, stolen, or otherwise compromised,
multiple layers of security:<br> there is no way to know it happened and what the new keys really are, and if the same user generated
<br> those keys. There is no centralised point where anyone can go to check if the compromised user has
0. I have provided identification to my domain name registrar, to ensure I can access the website I updated their keys, which means there must already have been at least one other secure channel in
rightfully own, should it be compromised, by providing identification to the domain name place before the compromise occurred. Even if there was, the security of endpoint devices,
registrar.<br> especially typical users, is much lower than a well protected corporation's servers, making even
<br> those secure channels questionable to trust. Should all secure channels be compromised, there is
1. I have provided identification to my virtual private server host, to ensure I can access the literally no way to know if the person you are communicating with is the real person or an imposter;
virtual private servers I rightfully rent, should they be compromised, by providing identification there is no root of trust. This point is fatal; game over. The only way to establish trust again
to the virtual private server host.<br> would be to physically meet and exchange keys.</p>
<br> <br>
2. I have pinned my website to a globally trusted certificate authority, Let's Encrypt, which is a <br>
trusted party to manage TLS certificates and ensure ownership of the domain when connecting to
it.<br> <h2 id="solution"><a href="#solution" class="h2"
<br> >Solution</a></h2>
3. I have enabled DNSSEC on my domain, so it is extremely difficult to spoof my domain to make you <p>I'll cut to the chase; there isn't a definitive solution. The best way to handle this situation
believe you're connecting to it when you're actually connecting to someone else's.<br> is to design your threat model and think about your reasoning for avoiding centralised platforms. Is
<br> it lack of trust of a specific company? Is it the possibility of centralised platforms going
While not the most secure implementation of a root of trust, it is the most secure implementation offline? Only by thinking logically and tactically can you solve both the issue of centralisation
currently available to me. While the domain name registrar or virtual private server host could and decentralisation. Often, one size fits all is never the correct approach, nor does it typically
tamper with my domain and data, they are the most trustworthy parties available. In its current work.</p>
form, decentralisation would make this impossible to implement in any form.</p> <br>
<br> <p>In order to avoid the issue of loss of trust due to lack of root of trust, all users' keys must
<h4>Conclusion</h4> be stored in a centralised location where all contacts are able to go to in case of compromise or to
<p>Do not demand anonymity; demand privacy and control of your own data. Complete anonymity makes it periodically check the state of keys and to see if they have changed. This centralised location
impossible to have a root of trust, and is typically never necessary. It is possible for someone requires some sort of identification to ensure that the user changing their keys is really the same
else to hold your keys, without them taking control of them and dictating what you can and cannot do person who initially signed up for the platform, using a trust-on-first-use (TOFU) model, which
(Twitter's misinformation policy comes to mind). If a platform is not listening to your or other isn't much different than what today's centralised platforms are already doing; the only difference
people's concerns about how it is being run, show those platforms that you will not stand for it, is who is controlling the location; trust is still present and required.</p>
and move to a different one. This may not be ideal, but it's not different to moving from one <br>
decentralised platform to another. Centralisation is not what is evil, the people in control of the <p>In order to have a root of trust, I have posted my keys to my website, which is protected by
platforms are what is potentially evil. Carefully, logically, and tactically, choose who to trust. multiple layers of security:<br>
Decentralisation doesn't do much for trust when you must still trust the operator of the <br>
decentralised platform, and are still subject to the possibly draconian policies of that 0. I have provided identification to my domain name registrar, to ensure I can access the website I
decentralised platform. If government is what you are trying to avoid, there is no denying it is rightfully own, should it be compromised, by providing identification to the domain name
feasibly impossible to avoid it; a government could always take down the decentralised platform, registrar.<br>
forcing you to move to another, and they could also take down the centralised key storage site <br>
mentioned earlier in this article. A government is not something you can so easily avoid. 1. I have provided identification to my virtual private server host, to ensure I can access the
Decentralisation does not solve the government issue. In order to live a happy, fun, and fulfilled virtual private servers I rightfully rent, should they be compromised, by providing identification
life, while protecting yourself against logical threats, there are only two words you must live by: to the virtual private server host.<br>
Threat model.</p> <br>
<br> 2. I have pinned my website to a globally trusted certificate authority, Let's Encrypt, which is a
<br> trusted party to manage TLS certificates and ensure ownership of the domain when connecting to
it.<br>
<br>
3. I have enabled DNSSEC on my domain, so it is extremely difficult to spoof my domain to make you
believe you're connecting to it when you're actually connecting to someone else's.<br>
<br>
While not the most secure implementation of a root of trust, it is the most secure implementation
currently available to me. While the domain name registrar or virtual private server host could
tamper with my domain and data, they are the most trustworthy parties available. In its current
form, decentralisation would make this impossible to implement in any form.</p>
<br>
<br>
<h2 id="conclusion"><a href="#conclusion" class="h2"
>Conclusion</a></h2>
<p>Do not demand anonymity; demand privacy and control of your own data. Complete anonymity makes it
impossible to have a root of trust, and is typically never necessary. It is possible for someone
else to hold your keys, without them taking control of them and dictating what you can and cannot do
(Twitter's misinformation policy comes to mind). If a platform is not listening to your or other
people's concerns about how it is being run, show those platforms that you will not stand for it,
and move to a different one. This may not be ideal, but it's not different to moving from one
decentralised platform to another. Centralisation is not what is evil, the people in control of the
platforms are what is potentially evil. Carefully, logically, and tactically, choose who to trust.
Decentralisation doesn't do much for trust when you must still trust the operator of the
decentralised platform, and are still subject to the possibly draconian policies of that
decentralised platform. If government is what you are trying to avoid, there is no denying it is
feasibly impossible to avoid it; a government could always take down the decentralised platform,
forcing you to move to another, and they could also take down the centralised key storage site
mentioned earlier in this article. A government is not something you can so easily avoid.
Decentralisation does not solve the government issue. In order to live a happy, fun, and fulfilled
life, while protecting yourself against logical threats, there are only two words you must live by:
Threat model.</p>
<br>
<br>
</body> </body>
</html> </html>