← Home
Provable Data Origin, The Platapus Method, A Brief.
2023 Jul 13
Provable Data Origin, The Platapus Method, A Brief.
1003 words
(Special thanks to Daniel Kang for feedback on
this article.)
Protocol for Location
And Time Attested
Phenomena of User
Sensor data. PLATAPUS. Because silly names are fun.
The platapus method will allow real world data creators to prove that
data was captured within a defined time and location window. The method
is constructed upon two key pillars. First, that a trusted attested
sensor can be used to guarantee that data was produced after another
piece of data. Second, that publishing a piece of data to a public
network guarantees that the data was produced prior to the
publication.
If these two properties are upheld then we can provably create data
within a time and location window.
Programmable Attested Sensor
The method relies primarily on a piece of trusted hardware, an
attested sensor. The proposed hardware is a sensor that can be preloaded
with arbitrary data. The sensor produces the data captured from the
world with a digital signature containing both the
captured data and the preloaded data. Because
the sensor is a trusted piece of hardware the signature assures that the
captured data was produced after the preloaded data.
Let's define some terms for the rest of the article:
preloaded data: arbitrary data that can be loaded
into the sensor.
captured data: the data captured by the
sensor.
sensor signature: a signature produced by the
sensor, and included in the captured data's metadata,
assuring that the captured data was produced after the
preloaded data.
Why must trusted hardware be used for this method?
A verifiable time window of the captured data would be impossible
without trusted hardware. A software based solution seems trivial to
exploit. Even with verifiable computation via a zero
knowledge proof, or private
computation with fully homomorphic
encryption, the software could still be fed arbitrary
preloaded data that may have been captured, or
synthetically produced, at any time before or after what is supposed to
be trusted captured data. There would be no guarantee that
the data was captured by a sensor, or that the data was authentic, and
produced after the preloaded data, breaking the method's
time window guarantee. We must ensure that the
captured data is produced after the
preloaded data has been generated to preserve the
properties of the method. A secure trusted hardware sensor seems the
only way to ensure the method's goals.
Time, Location, and
Publishing Networks
The method will also require the use of a decentralized network to
provide provable time and location claims. A network like ethereum could provide time claims for
the opening of the method's time window and also feasibly be used as a
data availability provider for publishing the captured data or sensor
signature, as a means of closing the method's time window.
The lack of location capabilities in ethereum would then point
towards a network like FOAM. FOAM is a
network of distributed nodes providing location services via LPWAN(Low
Power Wide Area Networks). When a user requests a presence claim from
FOAM they broadcast a small message (about 100 bytes) to the network
containing primarily of a cryptographic
signature.
Using FOAM we could request a presence claim and use it as the
preloaded data for our attested sensor. Then, request a
second presence claim with the hash of the captured data (alternative
parameters or signing methods could be used, options may be explored in
a future article), this effectively publishes a hash of the
captured data to the FOAM network. The two presence claims
give us the openings and closings of the time and location window for
the sensor data and are added to the metadata with a zk-proof assuring
both claims have followed the protocol.
There is not much to be done about withholding the data to be
published/released at a later time. However, if the two presence claims
are close to one another in both location and time (additionally, we
could tie the signature of the second presence claim to the attested
sensor that generated the captured data) we can be fairly
sure of where and when the sensor data was captured, but as the time
between presence claims increases the confidence in the location claim
becomes weaker. Each application using the method will have to define
some confidence interval between presence claims for its use case and if
the data doesn't meet that definition it may dismiss it. As long as the
attested sensor has not been compromised we can be sure that the data
was produced between the two presence claims.
If location claims are not desired we could go ahead and use the
latest ethereum blockhash as the preloaded data, and then
publish the sensor signature into ethereum's blobspace.
Using a decentralized network is nice because we can use its
trustless structure to prove things about data while using or
authenticating it on-chain, without relying on an additional trusted
party.
In practice a decentralized network could be substituted with a
trusted authority that would provide signed attestations for either, or
both, the opening and closing of the method's window. Publishing could
also take place on a centralized service such as a social media provider
or image host. However, introducing an additional centralized source
(after the manufacturer of the trusted sensor) reduces the security and
efficacy of the method. Composability is a property that cannot be
understated, and so prioritising decentralized networks should be the
preference of the method.
Conclusion
The platapus method relies on two main properties. Firstly, trusted
hardware can guarantee that digital data was produced after another
piece of data. And secondly, publicly publishing data ensures that data
was created prior to publication. An implementation of this method seems
far away at this point in time (May 2023), but after the development of
a programmable attested sensor, and the deployment of a widespread proof
of location network like FOAM, this method could be used as a proof
within standards like C2PA to
authenticate the origin of data, and within decentralized apps as
verifiable real world data.
Provable Data Origin, The Platapus Method, A Brief.
2023 Jul 13Hardware · Protocols
(Special thanks to Daniel Kang for feedback on this article.)
Protocol for Location And Time Attested Phenomena of User Sensor data. PLATAPUS. Because silly names are fun.
The platapus method will allow real world data creators to prove that data was captured within a defined time and location window. The method is constructed upon two key pillars. First, that a trusted attested sensor can be used to guarantee that data was produced after another piece of data. Second, that publishing a piece of data to a public network guarantees that the data was produced prior to the publication.
If these two properties are upheld then we can provably create data within a time and location window.
Programmable Attested Sensor
The method relies primarily on a piece of trusted hardware, an attested sensor. The proposed hardware is a sensor that can be preloaded with arbitrary data. The sensor produces the data captured from the world with a digital signature containing both the
captured dataand thepreloaded data. Because the sensor is a trusted piece of hardware the signature assures that the captured data was produced after the preloaded data.Let's define some terms for the rest of the article:
preloaded data: arbitrary data that can be loaded into the sensor.captured data: the data captured by the sensor.sensor signature: a signature produced by the sensor, and included in thecaptured data's metadata, assuring that thecaptured datawas produced after thepreloaded data.Why must trusted hardware be used for this method?
A verifiable time window of the captured data would be impossible without trusted hardware. A software based solution seems trivial to exploit. Even with verifiable computation via a zero knowledge proof, or private computation with fully homomorphic encryption, the software could still be fed arbitrary
preloaded datathat may have been captured, or synthetically produced, at any time before or after what is supposed to be trustedcaptured data. There would be no guarantee that the data was captured by a sensor, or that the data was authentic, and produced after thepreloaded data, breaking the method's time window guarantee. We must ensure that thecaptured datais produced after thepreloaded datahas been generated to preserve the properties of the method. A secure trusted hardware sensor seems the only way to ensure the method's goals.Time, Location, and Publishing Networks
The method will also require the use of a decentralized network to provide provable time and location claims. A network like ethereum could provide time claims for the opening of the method's time window and also feasibly be used as a data availability provider for publishing the captured data or sensor signature, as a means of closing the method's time window.
The lack of location capabilities in ethereum would then point towards a network like FOAM. FOAM is a network of distributed nodes providing location services via LPWAN(Low Power Wide Area Networks). When a user requests a presence claim from FOAM they broadcast a small message (about 100 bytes) to the network containing primarily of a cryptographic signature.
Using FOAM we could request a presence claim and use it as the
preloaded datafor our attested sensor. Then, request a second presence claim with the hash of the captured data (alternative parameters or signing methods could be used, options may be explored in a future article), this effectively publishes a hash of thecaptured datato the FOAM network. The two presence claims give us the openings and closings of the time and location window for the sensor data and are added to the metadata with a zk-proof assuring both claims have followed the protocol.There is not much to be done about withholding the data to be published/released at a later time. However, if the two presence claims are close to one another in both location and time (additionally, we could tie the signature of the second presence claim to the attested sensor that generated the
captured data) we can be fairly sure of where and when the sensor data was captured, but as the time between presence claims increases the confidence in the location claim becomes weaker. Each application using the method will have to define some confidence interval between presence claims for its use case and if the data doesn't meet that definition it may dismiss it. As long as the attested sensor has not been compromised we can be sure that the data was produced between the two presence claims.If location claims are not desired we could go ahead and use the latest ethereum blockhash as the
preloaded data, and then publish thesensor signatureinto ethereum's blobspace.Using a decentralized network is nice because we can use its trustless structure to prove things about data while using or authenticating it on-chain, without relying on an additional trusted party.
In practice a decentralized network could be substituted with a trusted authority that would provide signed attestations for either, or both, the opening and closing of the method's window. Publishing could also take place on a centralized service such as a social media provider or image host. However, introducing an additional centralized source (after the manufacturer of the trusted sensor) reduces the security and efficacy of the method. Composability is a property that cannot be understated, and so prioritising decentralized networks should be the preference of the method.
Conclusion
The platapus method relies on two main properties. Firstly, trusted hardware can guarantee that digital data was produced after another piece of data. And secondly, publicly publishing data ensures that data was created prior to publication. An implementation of this method seems far away at this point in time (May 2023), but after the development of a programmable attested sensor, and the deployment of a widespread proof of location network like FOAM, this method could be used as a proof within standards like C2PA to authenticate the origin of data, and within decentralized apps as verifiable real world data.