From 47c0d7ea974b89fc889d3dddeeeffa06390f11e0 Mon Sep 17 00:00:00 2001 From: inference Date: Thu, 30 Jun 2022 01:52:14 +0100 Subject: [PATCH 1/4] Add Blog #2 - Untrusted: The Issue with Decentralisation. --- ...usted-the-issue-with-decentralisation.html | 129 ++++++++++++++++++ 1 file changed, 129 insertions(+) create mode 100644 blog/untrusted-the-issue-with-decentralisation.html diff --git a/blog/untrusted-the-issue-with-decentralisation.html b/blog/untrusted-the-issue-with-decentralisation.html new file mode 100644 index 0000000..1252fe2 --- /dev/null +++ b/blog/untrusted-the-issue-with-decentralisation.html @@ -0,0 +1,129 @@ + + + +Inferencium Network - Blog - Untrusted: The Issue with Decentralisation + + + +

Blog - #2

+
+

Untrusted: The Issue with Decentralisation

+
+

Posted: 2022-06-29 (UTC+00:00)

+

Updated: 2022-06-29 (UTC+00:00)

+
+

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.

+
+

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.

+
+In the decentralised model, keys are kept on the users' devices, in their
+possession. While this soveriegnty is welcomed, it indroduces 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.

+
+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:
+
+1. 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.
+
+2. 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.
+
+3. I have pinned my website to a globally trusted certificate authority,
+Let's Encrypt, which is a trsuted party to manage TLS certificates and
+ensure ownership of the domain when connecting to it.
+
+4. 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 a root of trust, but 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.
+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 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 isn't 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.

+
+
+
+Back + + From 21867b5902ead506d92ea007af6574fa0ce27a46 Mon Sep 17 00:00:00 2001 From: inference Date: Thu, 30 Jun 2022 01:54:37 +0100 Subject: [PATCH 2/4] Add link to Blog #2. --- blog/blog.html | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/blog/blog.html b/blog/blog.html index 7bdeea3..33019a4 100644 --- a/blog/blog.html +++ b/blog/blog.html @@ -7,6 +7,10 @@

Blog


+

2022-06-29

+

#2 - Untrusted: The Issue with Decentralisation

+
+

2022-01-29

#1 - systemd Insecurity


From 85da8fe17a1832f7671869d52c5a8d3da1d57196 Mon Sep 17 00:00:00 2001 From: inference Date: Thu, 30 Jun 2022 02:02:08 +0100 Subject: [PATCH 3/4] Fix paragraph formatting. Update Conclusion section. --- ...usted-the-issue-with-decentralisation.html | 48 ++++++++++--------- 1 file changed, 25 insertions(+), 23 deletions(-) diff --git a/blog/untrusted-the-issue-with-decentralisation.html b/blog/untrusted-the-issue-with-decentralisation.html index 1252fe2..8937d14 100644 --- a/blog/untrusted-the-issue-with-decentralisation.html +++ b/blog/untrusted-the-issue-with-decentralisation.html @@ -37,7 +37,7 @@ 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
+

In the decentralised model, keys are kept on the users' devices, in their
possession. While this soveriegnty is welcomed, it indroduces 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,
@@ -63,7 +63,7 @@ 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,
+

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
@@ -73,7 +73,7 @@ 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,
+

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

1. I have provided identification to my domain name registrar, to ensure I
@@ -98,29 +98,31 @@ 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.
+implement in any form.


Conclusion

Do not demand anonymity; demand privacy and control of your own data.
-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 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 isn't 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.

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




From 952daf263a14dc50a3c8c4c012cc85540cd42214 Mon Sep 17 00:00:00 2001 From: inference Date: Thu, 30 Jun 2022 02:03:56 +0100 Subject: [PATCH 4/4] Update both posted and updated dates, since they were not pushed to stable branch before date change. --- blog/untrusted-the-issue-with-decentralisation.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/blog/untrusted-the-issue-with-decentralisation.html b/blog/untrusted-the-issue-with-decentralisation.html index 8937d14..0bf793d 100644 --- a/blog/untrusted-the-issue-with-decentralisation.html +++ b/blog/untrusted-the-issue-with-decentralisation.html @@ -9,8 +9,8 @@

Untrusted: The Issue with Decentralisation


-

Posted: 2022-06-29 (UTC+00:00)

-

Updated: 2022-06-29 (UTC+00:00)

+

Posted: 2022-06-30 (UTC+00:00)

+

Updated: 2022-06-30 (UTC+00:00)


Introduction

A recent trend is seeing people move towards decentralised services and