[Standards] Some thoughts on possible OMEMO trust models
jonas at wielicki.name
Mon Feb 20 06:50:09 UTC 2017
-----BEGIN PGP SIGNED MESSAGE-----
On Sonntag, 19. Februar 2017 22:32:00 CET Vanitas Vitae wrote:
> As part of my bachelor thesis
> I thought about future development of the OMEMO protocol extension
I haven’t looked into OMEMO yet myself, but I think I can nevertheless provide
> [… current situation and issues …]
> Variant I:
> Let's assume, I use device A and trusted some contact devices.
> What I could do is:
> * Whenever I trust a device "a" on my device A, I sign the fingerprint
> of "a"'s identity key with my own identity key and upload the signature
> to a private pubsub node (lets call it the "trust-node-A").
> * When I start to use a new device B, I can fetch the contents of A's
> trust-node. When I decide on B, that I trust device A, I can check all
> the signatures in A's trust-node and automatically have transitive
> trust all devices trusted by A.
> The downside of this is, that there is a "trust gradient", meaning that
> older devices are higher up in the trust hierarchy than newer ones (what
> happens, when you lose device A?) Also distrusting devices might be a
> For distrusting a device, we could sign not only the fingerprint of the
> device, but also a state indicator like "trust:FINGERPRINT"
> (trust-proof) or "distrust:FINGERPRINT" (distrust-proof). That way,
> devices could automatically ignore/delete trust-proofs, when there is
> one or more distrust-proof.
This is probably akin to the GPG model of trust. The gradient is not
neccessarily a bad thing, but if that’s of concern, mirroring the trust
signatures of another device (once or like a master-master replication) with
the own device key should be no problem.
> Possible problem: What happens when an attacker distrusts all your
> devices or creates paradox trust decisions?
Hold on, what kind of attacker? Please state an attacker model here: what can
the attacker do, where does it sit in the grand scheme of things?
A server-level attacker should not be able to add trust between devices (only
remove it by breaking the signatures or removing items or nodes from the
Likewise, a device-level attacker should not be able to add trust between
devices other than the device it is controlling. Again, removal is possible
> Eg. assume we have devices
> A,B,C. A trusts B, B trusts C, C trusts A.
> B distrusts A, C distrusts B, A distrusts C. How to resolve? You might
> decide by counting, which device is trusted/distrusted by the majority
> of device, but that would defeat the purpose of the whole system, since
> again trust decisions must be made on each device. Is there something
> useful for this in the OpenPGP-World?
That might be worth looking into (how GPG handles conflicting trust statements
of equally trusted keys). A very simple solution (depending on the attacker,
I’m not quite sure which scenario you have in mind) would be to state an error
in that situation and let the user fix it manually.
> Variant II:
> This could be handy for IoT and is less complicated (I hope :D).
> Since IoT devices often do not have an easy to use interface for
> configuration, it might be a hassle to do trust decisions on them (which
> other devices should be trusted).
> To improve this, we might add a master-device, so each device only must
> trust the master. The master decides, which devices are trusted by
> signing their identity keys and publishing the signature on the
> trust-node. Each thing looks up the trust-node to decide, which other
> things to trust. When a device is not in the trust node, it must be
> (I don't know, how IoT is done with xmpp. In this model, all things have
> the same jid. I don't know, whether this is also possible with unique
> jids for each thing.)
I think normally you’d have unique jids for each thing.
But this should be possible to do, if you go with Variant I and simply make
the pubsub node optionally readable to other users (not only for your own).
This enables a Web-of-Trusty-Usage, from which the IoT devices can benefit (by
trusting all keys their owner trusts, obtained via the PubSub node of their
Interesting topic for sure, will follow the discussions!
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
More information about the Standards