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.
+
+
+
+
+ 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.
-
-
-
-
- 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.
-
-
-
-
- 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:
-
- - 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.
- - 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.
- - 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.
- - 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.
-
-
-
- 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 (X'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.
-
-
-
+
+
+
+ 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:
+
+ - 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.
+ - 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.
+ - 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.
+ - 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.
+
+
+
+ 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 (X'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.
+
+