Proof of Presence - PoP-NFT

[Grayman]

I think that the preponderance of smartphones enables us to imagine adding spacetime data to the blockchain. I envision an end-user minted NFT with encrypted location data.

There are a thousand reasons why you might want to do this.

But let’s consider some dangerous areas and potential drawbacks of this idea.

First of all there is question of privacy, or lack thereof. These NFT’s would originate on the user’s device, and also would be stored on chain in a separate receive addy within the user’s mobile wallet. But they would be encrypted, so the only information that someone could deduce would be that the user checked in at a specific location [ETA: I meant “somewhere”]. Unless they have the encryption key… but we’ll come back to that.

Now, this isn’t just putting google maps location data on the blockchain… first of all, the end user decides when to mint the NFT. More importantly, this uses the phone’s GPS/GLONASS/Galileo sensor, when it is available. It simply leaves an encrypted time and date stamp, along with gps coordinates, on chain in the user’s wallet.

What if we’re using this in order to prove presence for some legal purpose, like showing up for a meeting with a suspect? Well, isn’t this what blockchain is made for? For recording indelible, indisputable truth?

That one is the rub. Of course we can’t plan for gps jamming or other means of hardware hacking, except to review the details of the encrypted nft, and possibly mark it for review based on circumstances. But what about ensuring that the nft originated from the user’s device? How can we prove witness to important events if someone could just create a fake proof of presence from their mom’s basement?

My idea is to tie it to the device, and to use the official Google Play Store to distribute an (open source) app that incorporates a checksum into the encryption for the data on that device that includes the md5 of its own executable, as well as the MEID, and of course the user’s strong password.

I realize they could hand their phone to a surrogate, but I have ideas for that too. This is a tool for the end user, and if used appropriately that can be shown. But the data remains in their hands.

I am struggling to learn Kotlin, and make this happen on Android first.

Is the idea of using an md5 on the same executable that delivers the encryption and mints the nft viable? Would this succeed in proving that a fraudulent NFT was created using some software that fakes the gps coordinates?

My aim would be for this to be standardized and certified via Google’s dev program. The code would be open source, so it would reveal that it queries MEID and executable checksum, in addition to gps coordinates and UTC.

But what if they run an adjusted version from their mom’s basement that specifies all of those inputs and fakes the gps coordinates to simulate “proof of presence” when they were actually in the basement eating cheetos… would we know?

Is there a way to prove it within reason? I can think of several other methods, but they complicate matters. I want PoP-NFT v1.0 to be simple enough to not require ipfs, and just record the necessary info to prove you were at a certain place at a certain time. I want it to run as a dap on the Ergo mobile wallet.

Can anyone more experienced in programming and cryptography comment, please?

[Grayman]

Let me be a little more specific about the encryption mechanism I envision for these PoP-NFT’s.

The app will be installed on the user’s device, and it will utilize two passwords, one strong and private, the other for sharing (can be changed).

The sharing password is used to encrypt/decrypt the PoP-NFT, and can be used by a vendor or other partner to verify your proof of presence, if you share it. By decrypting the PoP-NFT, you would uncover another encrypted file, as well as the key used to decrypt it. This key is only applicable to this nft, because it is generated by using a strong (private) user password to encrypt the following data: MEID, OS version, Pop-NFT version, PoP.exe checksum, UTC seconds, and decimal components of the latitude and longitude. The vendor will not receive any of that data, because they do not get the strong private password. But they will get the one-time key. And that key is what unlocks the encrypted core data: The GPS coordinates, and the UTC at the time the NFT creation transaction was made.

So, going backwards, we see that spacetime data is recorded and encrypted by a unique key, which is generated by a strong private password and device-specific data, which is, in turn, all encrypted using a lesser password that can be shared with vendors or partners that you want to whom you want to prove presence.

The nature of the encryption set up would make it very unlikely that an external attacker could successfully forge a self-consistent simulation of such an NFT, not least of which because they would need access to your send address to generate the NFT in the first place. A dedicated sneak could simulate their presence in a place where they are not, that is true. But they would need to work at it. And as I said, I can think of a number of ways to deal with the digital identity issue, especially when the person is supposedly right at hand.

Now you might also wonder how this could be used in permissionless smart contracts when it seems that all power lies in the hands of the end user. That is why I took pains to suggest a sharing password, so that other parties could verify your presence, and use the shared password (and sending address) to unlock the next stage of the contract.

Anyone picking up what I’m laying down here?

Is this just crazy?

Has anyone else done this type of thing here, or on another blockchain?

Don’t be shy to tell me this is stupid. I welcome any criticism, especially if it might be fatal.

[jossemii]

Interesting idea. I think the most difficult part is trusting the real geolocation.

How do you ensure that the app has not been modified?

This could be a starting point: Trusty. However, I’m not sure if it’s sufficient.

[Grayman]

That is interesting for some other ideas I have about a dedicated secure comms device.

With regard to your question, I have a few comments. There might be a way to do this using a third party witness, but that would still only abstract the trust further.

I think what matters most is the final application. I feel like this is as secure as your existing wallet from external influence, and so the only one to doubt is yourself.

Looked at in this context, the security is good enough if the incentives are aligned. If I am using this as a (password protected) way to store the location of some buried treasure, then I am going to make sure that I use the application correctly.

If I am using it set up a scavenger hunt, and compare your progress against various checkpoint before you get the next message, then both of our incentives are aligned.

I don’t think I can use this to put a fake PoP-NFT into your wallet without your knowledge, so in that case it is quite secure.

[jossemii]

I don’t quite see why the incentives are aligned in your example. Players will still have the incentive to fake their location. Remember the case of Pokémon Go, where people ended up playing from home, moving their character through major cities with modified versions of the app that allowed them to change their location. Similarly, if I think the treasure is at point X, but I don’t want to travel there, I could modify my location. Of course, if we say, for example, that they have to scan a QR code at the treasure’s location, it’s not the same, but then I don’t see the purpose of the location.

[Grayman]

Well in the case of the buried treasure that is the incentive, since the coordinates are encrypted, so you want them to be accurate.

It’s interesting to me that in the case of a closed source application like Pokemon go, that they could not find a way to ensure legitimate input.

I’ll think a little bit more about this, and get back to you.