An dieser Stelle taucht jedoch das Problem der Vertrauenswürdigkeit wieder auf. Das Oracle kann Daten der Sensoren ändern, bevor sie die Datensatzkette erreichen. Sobald die übertragenen Daten in der Datensatzkette sind, kann ihnen ohne einen TTP vertraut werden – aber den Oracle-Anbietern muss vertraut werden. Die Oracle-Anbieter lassen sich von zentralisierten Zertifizierungssystemen zertifizieren. Das bedeutet jedoch, der TTP ist wieder da (nur in einer anderen Form) und gleichzeitig zentralisiert (wie Verisign für vertrauenswürdige Webseiten). Ein einfacher DoS-Angriff auf die Zertifikat-Anbieter oder auf die Oracles selbst könnte das gesamte IoT-System außer Gefecht setzen.
Eine Option wäre, die Daten an verschiedene unterschiedliche Oracles bereitzustellen und Redundanz zu verwenden. Jedoch wird es den meisten Organisationen zu teuer werden, ausreichend Oracles einzurichten. Ein Open-Source-Oracle-Server, der universell gehostet werden kann, könnte die Lösung für die Bereitstellung der Daten, aber nicht für die Frage der Vertrauenswürdigkeit sein.
Ein Zertifikat „vertraut“ nur dem Oracle-Knotenpunkt. Der Sensor, der die Informationen bereitstellt, könnte kompromittiert sein und das Oracle würde es nicht wissen, oder – noch schlimmer – es „wäre ihm egal“. Die Oracle-Hersteller stellen nur den Service bereit, Informationen in die Datensatzkette zu bringen. Sie können realistisch nicht alle Sensor-Anbieter überprüfen.
Natürlich könnten die Sensor-Anbieter sich ebenfalls selbst zertifizieren und sagen, ihre Hardware/Firmware lässt sich nicht hacken und ist vertrauenswürdig. Aber hier taucht wieder das TTP-Problem auf, Kundenbindung und höhere Kosten für Ihr System.
Mit der Einführung eines solchen TTPs ist der Einsatz einer dezentralen vertrauenswürdigen Datensatzkette fragwürdig. Ein zentralisiertes „Standard“-Datenbank-Netzwerk bietet die gleiche Funktionalität mit, letztendlich, den gleichen Nachteilen.
