In the second half of 2017, I took part in a “capstone project” as part of the completion of my Masters in Software Development. This project required a significant amount of effort on the part of myself and my team over the course of 3 months, and I’m quite proud of result, so I’m going to share it with everyone. This blog post will give a high-level overview of the scope of the project, and I’ll do a couple follow up posts getting into the nitty-gritty of the development and how everything works together.
The team for this project consisted of 5 members. As a part of this project was research-based, three of our team members focused on research and working on the project plan documents. Another team member and I were the two lead developers for the project, and I also acted as team leader and point of contact for the client.
The project itself came from a Researcher at a university in Sarawak, Malaysia. The researcher had previously worked with a group of bachelor students on a basic proof-of-concept and wanted us to develop it further.
The main goals were to develop a blockchain-based tracking system for a supply chain, allowing the movement of goods to be tracked from production to its final destination. We were given free range with how we would go about this, and were allowed to explore any technology we felt might benefit the project. Now, there’s quite a lot to unpack in a “Blockchain-Based Tracking System”, and blockchain being a developing field, we spent a lot of time finding as much information as we could on the topic of product tracking.
The blockchain we chose to develop on was NXT. We worked on the NXT testnet, so not the live blockchain, but this could have been done on any blockchain that allows some sort of minimal data storage in transactions. We chose NXT because it has amazing API documentation, and a really accessible testnet that we could run on without incurring any costs.
Our client wanted the system to be able to track the individual locations of products in a supply chain, whilst knowing for certain which locations products had passed through. Quite a challenge. We put together a document going over research that has been performed in this area, and the solution we decided to go with. I’ll go through this in more depth in the next section.
This project also suffered from a bit of scope creep as well. Whilst we thought we had locked down the scope of the project several weeks in, further meetings with our client revealed they had larger plans for our project, and we tried to accommodate them where possible.
The above Architecture Diagram shows an overview of our solution. Whilst it may look straight forward enough, the servers and mobile applications all communicate with each other, and results in quite a complicated application.
To start with, we identified the two main parties involved in our supply chain: Producers and Users. We considered a ‘Producer’ to be a party that made a product or received a product and passed it onto another. In other words, a Producer in our application was any party in the supply chain that was not directly purchasing a product off the shelf. And a user therefore, would be a customer purchasing a product from a store (the final Producer in a product’s life cycle), and wanting to know where a product had been created and shipped from. Producers would be the only party updating information on the platform, and Users would be reading the culmination of information of a product.
Part of our requirement was to have individually identifiable products in the supply chain. We found that the most intuitive solution to this would be to have some kind of unique identifier for each product, and create a QR code to be placed on each product. But what would we use to identify a product? We could use a unique number or string to identify a product, store this in a database, and then make updates to the database when the product is moved. But we can do better than that. We were tasked with relying heavily on Blockchain to ensure data immutability, and that not one party had complete control over the data. So a traditional database would not do. Instead, we decided that each product would be represented by a keypair on a blockchain, and that whenever a product is created/moved, a Producer would create a transaction to that keypair.
Now this is where things start getting hairy, so I’ll come back to exactly how products are created and moved in a later post. Just know that each product is provided with a unique ‘account’ on a blockchain network, and Producers can send updates to these accounts when a Product changes location. A consumer can then scan a product’s QR code and then retrieve this information from the blockchain.
Now that you have an idea of how our supply train tracking system worked, I can delve a bit deeper into the main hurdle we had to overcome in developing and researching this project: Proof-of-Location. On the surface it sounds easy.
“We have GPS, so we can know where something is with an accuracy of less than a meter. How difficult can it be to create some proof of that?”
It turns out that it actually is quite difficult. If you want to do it in a way that cannot be faked or spoofed. Or at least make it extremely difficult to be tampered with. There were several options we investigated, after scouring literature on the subject for a week or two. I mentioned our research document earlier, but I’ll outline the best potential option for each available technology.
Brambilla, Amoretti & Zanichellia 2016 - Bluetooth
This paper was given to us by our client as a starting point for our research. In it, the researchers outline a sort of blockchain-style, decentralised consensus for devices to be able to prove the location of each other, without revealing any information about themselves. It’s quite a theoretical paper, and they don’t get into much detail on the technology that could be used to make this work. However they suggest that mobile devices with access to the internet (WiFi or cellular) and are able to connect to other devices using a short-range communication technology like Bluetooth would be most suitable. These mobile devices would therefore be able to use other devices in the surrounding area as “witnesses” to prove their location.
(Brambilla, Amoretti, Zanichellia, 2016)
Lin & He, 2014 - WiFi
This research focused on using WiFi to prove a device’s location within a set area. They propose a system that maps out an area based on its WiFi coverage. Users that have signal strengths from certain access points would be known to be in that location, and could be pinpointed to a great accuracy. Relatively straightforward, but requiring the targeted area to have sufficient WiFi coverage. Similar research by Saroiu & Wolman, 2009 talks about getting “location proofs” through wireless infrastructure such as telephone towers in addition to WiFi access points.
(Lin, He, 2014)
McElrath, 2016 - Satellites
There are interesting but more complicated solutions, involving multiple satellites continuously sending ‘pings’ down to Earth (such as GPS satellites). The idea being, that you would generate a hash and send them to multiple satellites at the same time. These satellites would then attach this hash to their next ping as soon as possible, and all those receiving would see that hash. They would be able to see it had been created at a certain time, and by measuring the time differences between when the satellites received it, would be able to pin-point the location the hash was generated.
The solution we came up with didn’t come from a single specific research paper, but rather a combination of several. To be able to solve the proof-of-location, we created a Bluetooth “beacon”, which would sign received requests with a private key contained within the device. The matching public key for this device would be distributed by the Producer, and be known to have originated at the Producer’s location. Due to the short-range nature of Bluetooth, you could be sure that the location-proof had been obtained within range of the beacon. Of course, this all depends on the assumption that the Bluetooth beacon itself hasn’t been compromised. Which I will go into below. But it is already significantly better than just relying on a producer to enter a location truthfully.
Of course there are many ways to improve this. Such a “Bluetooth Beacon” could also have a satellite dish to prove its location by measuring packet delays from communications satellites. In practicality, relying on a 3rd party to distribute and install these beacons at locations in a supply chain is not too much of a stretch, and we felt that this was the best combination of security and simplicity.
Our project, like any other, had several assumptions we had to make in order for our solution to work. While some proof-of-concept projects, created in a short period of time may have assumptions that would mean it’s not feasible in the real world, we feel that our project’s assumptions are more like footnotes to the project. They make the project complete.
Publicly Available Information
The first assumption we made, is that participants in the supply chain can distribute proof that they are the owner of a certain keypair. This information would essentially be a public key, that people could use to verify that encrypted information had come from the holder of the private key. This information could be displayed on their website, posted on social media, and is essentially a pre-shared key.
In addition to proving ownership of a keypair, Producers would also need a way to provide information on the products traversing the supply chain. Blockchains are great at ensuring data cannot be changed, access to transactions and smart contracts etc. But they are not great at storing large amounts of data. You can imagine such information as a title, product Id, batch ID, items included, expiry date, etc. All this information cannot be stored on the blockchain. Instead the information can be combined and then hashed, and only the hash is stored with the product. This information then needs to be distributed by the Producer, so that anyone can access it, hash the information, and make sure it matches the hash on the product. You can then be sure that the information actually does belong to the product.
We accomplished this by using what we called a “Caching Server”, as the destination where all the publicly available information was held. But you could imagine this information coming from multiple sources, and not relying on one server as a source of truth.
Security of Bluetooth Beacons
The other assumption we had in this project is that the Bluetooth beacons had sufficient security, both in terms of the device itself, but also its installation at the Producer’s site. As the beacon is holding a private key that is used to sign location requests, it needs to be made sure that this private key cannot be accessed by anyone else. In the event of a private key being hacked/leaked, the Producer could create a new one and distribute that. Knowledge of the exposed key would propagate, and any products affected could display a warning informing of its doubtfulness. Future keys from the producer could then be trusted.
This was a super long post, and I definitely didn’t mean to go into so much depth. There’s still a lot to go into, like how the QR codes are created, how transactions are signed, and how products get moved between Producers. If you’re interested in seeing more about how this all worked, you can check out our Detailed Overview document, or you can wait until I release some more posts on this.
This really was a huge project, and I’d love to keep sharing what we were able to make. If you’re working on a similar project, or have any questions, please get in touch with me! I will be more than happy to discuss and answer any questions you might have.
Brambilla, G, Amoretti, M & Zanichelli, F 2016, “Using Blockchain for Peer-to-Peer Proof-of-Location”
Lin, X & He, W 2014, “WiLoVe: A WiFi-coverage based Location Verification System in LBS”
Saroiu, S & Wolman, A 2009, “Enabling new mobile applications with location proofs”