[Standards] Some thoughts on possible OMEMO trust models

Jonas Wielicki jonas at wielicki.name
Mon Feb 20 06:50:09 UTC 2017

Hash: SHA512


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 
> (xep-0384).

I haven’t looked into OMEMO yet myself, but I think I can nevertheless provide 
some input.

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

Sounds elegant-ish.

> 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
> problem:
> 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 
via PubSub.

> 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
> distrusted.
> (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!

Good luck,


More information about the Standards mailing list