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