From e7a1932efd074afa625a7c1e3719d039fe68c4a2 Mon Sep 17 00:00:00 2001 From: inference Date: Sun, 11 Dec 2022 20:03:44 +0000 Subject: [PATCH] Update back-end code to new 100-120 column coding style. --- ...usted-the-issue-with-decentralisation.html | 172 ++++++++---------- 1 file changed, 75 insertions(+), 97 deletions(-) diff --git a/blog/untrusted-the-issue-with-decentralisation.html b/blog/untrusted-the-issue-with-decentralisation.html index 9c6dc40..23cc09a 100644 --- a/blog/untrusted-the-issue-with-decentralisation.html +++ b/blog/untrusted-the-issue-with-decentralisation.html @@ -5,7 +5,7 @@ - + @@ -38,116 +38,94 @@

Introduction

-

A recent trend is seeing people move towards decentralised services and -platforms. While this is reasonable and I can understand why they are doing -such a thing, they are seemingly doing it without thinking about the -possible consequences of doing so. The issue with decentralisation is -trust; there is no way to pin a key to a specific person, to ensure that -you are communicating with the same person you are supposed to be -communicating with. In this article, I will discuss some of the security -issues with the decentralised model.

+

A recent trend is seeing people move towards decentralised services and platforms. While this is +reasonable and I can understand why they are doing such a thing, they are seemingly doing it without +thinking about the possible consequences of doing so. The issue with decentralisation is trust; +there is no way to pin a key to a specific person, to ensure that you are communicating with the +same person you are supposed to be communicating with. In this article, I will discuss some of the +security issues with the decentralised model.


Example: Messaging

-

When it comes to messaging your contacts on a centralised platform, -such as Twitter or Facebook, 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 strong enough to not be guessed, whether via personal guessing -or exhaustive search. The trust in this centralised model is the high -security these platforms have. It is extremely unlikely that anyone other -than a government would be able to access the accounts stored on such -platforms' servers, which makes the physical security trusted. As for -remote security, should a user's password be compromised, it can typically -be reset if the user can prove they are the owner of the account via some -form of identification; this is where the trust issue of decentralisation -occurs.

+

When it comes to messaging your contacts on a centralised platform, such as Twitter or Facebook, +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 +strong enough to not be guessed, whether via personal guessing or exhaustive search. The trust in +this centralised model is the high security these platforms have. It is extremely unlikely that +anyone other than a government would be able to access the accounts stored on such platforms' +servers, which makes the physical security trusted. As for remote security, should a user's password +be compromised, it can typically be reset if the user can prove they are the owner of the account +via some form of identification; this is where the trust issue of decentralisation occurs.


-

In the decentralised model, keys are kept on the users' devices, in their -possession. While this 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, -there is no way to know it happened and what the new keys really are, and -if the same user generated those keys. There is no centralised point where -anyone can go to check if the compromised user has updated their keys, -which means there must already have been at least one other secure channel -in place before the compromise occurred. Even if there was, the security -of endpoint devices, especially typical users, is much lower than a well -protected corporation's servers, making even those secure channels -questionable to trust. Should all secure channels be compromised, there is -literally no way to know if the person you are communicating with is the -real person or an imposter; there is no root of trust. This point is fatal; -game over. The only way to establish trust again would be to physically -meet and exchange keys.

+

In the decentralised model, keys are kept on the users' devices, in their possession. While this +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, +there is no way to know it happened and what the new keys really are, and if the same user generated +those keys. There is no centralised point where anyone can go to check if the compromised user has +updated their keys, which means there must already have been at least one other secure channel in +place before the compromise occurred. Even if there was, the security of endpoint devices, +especially typical users, is much lower than a well protected corporation's servers, making even +those secure channels questionable to trust. Should all secure channels be compromised, there is +literally no way to know if the person you are communicating with is the real person or an imposter; +there is no root of trust. This point is fatal; game over. The only way to establish trust again +would be to physically meet and exchange keys.


Solution

-

I'll cut to the chase; there isn't a definitive solution. The best way -to handle this situation is to design your threat model and think about -your reasoning for avoiding centralised platforms. Is it lack of trust of -a specific company? Is it the possibility of centralised platforms going -offline? Only by thinking logically and tactically can you solve both the -issue of centralisation and decentralisation. Often, one size fits all is -never the correct approach, nor does it typically work.

+

I'll cut to the chase; there isn't a definitive solution. The best way to handle this situation +is to design your threat model and think about your reasoning for avoiding centralised platforms. Is +it lack of trust of a specific company? Is it the possibility of centralised platforms going +offline? Only by thinking logically and tactically can you solve both the issue of centralisation +and decentralisation. Often, one size fits all is never the correct approach, nor does it typically +work.


-

In order to avoid the issue of loss of trust due to lack of root of trust, -all users' keys must be stored in a centralised location where all contacts -are able to go to in case of compromise or to periodically check the state -of keys and to see if they have changed. This centralised location requires -some sort of identification to ensure that the user changing their keys is -really the same person who initially signed up for the platform, using a -trust-on-first-use (TOFU) model, which isn't much different than what -today's centralised platforms are already doing; the only difference is who -is controlling the location; trust is still present and required.

+

In order to avoid the issue of loss of trust due to lack of root of trust, all users' keys must +be stored in a centralised location where all contacts are able to go to in case of compromise or to +periodically check the state of keys and to see if they have changed. This centralised location +requires some sort of identification to ensure that the user changing their keys is really the same +person who initially signed up for the platform, using a trust-on-first-use (TOFU) model, which +isn't much different than what today's centralised platforms are already doing; the only difference +is who is controlling the location; trust is still present and required.


-

In order to have a root of trust, I have posted my keys to my website, -which is protected by multiple layers of security:
+

In order to have a root of trust, I have posted my keys to my website, which is protected by +multiple layers of security:

-0. I have provided identification to my domain name registrar, to ensure I -can access the website I rightfully own, should it be compromised, by -providing identification to the domain name registrar.
+0. I have provided identification to my domain name registrar, to ensure I can access the website I +rightfully own, should it be compromised, by providing identification to the domain name +registrar.

-1. I have provided identification to my virtual private server host, to -ensure I can access the virtual private servers I rightfully rent, should -they be compromised, by providing identification to the virtual private -server host.
+1. I have provided identification to my virtual private server host, to ensure I can access the +virtual private servers I rightfully rent, should they be compromised, by providing identification +to the virtual private server host.

-2. I have pinned my website to a globally trusted certificate authority, -Let's Encrypt, which is a trusted party to manage TLS certificates and -ensure ownership of the domain when connecting to it.
+2. I have pinned my website to a globally trusted certificate authority, Let's Encrypt, which is a +trusted party to manage TLS certificates and ensure ownership of the domain when connecting to +it.

-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.
+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.

-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.

+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.


Conclusion

-

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.

+

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.