Akvo Phone Security Analysis
From Akvo Labs
Security model for safety critical mobile phone applications operating in untrusted environments.
Please contact Vinay Gupta with ideas and feedback, or post right here. Thank you.
Framing the problem
Akvo's work is safety critical. A leak through which money escapes without doing good harms somebody's health and is a statistical risk of death. This is a harsh statement of the problem, but in the event that "wired aid" programs like Akvo or Kiva wind up discredited because of rampant fraud, a lot of people are going to suffer. It is therefore imperative that the integrity of the business process is maintained.
That problem is much more than technical in nature. Let us consider an example.
We have three groups which use the Akvo system:
- Funding Partners
- Support Partners
- Field Partners
Plus three other relevant and affected parties:
- Funding Public (donors, including indirectly through governments via taxation)
- Akvo Staff
- Field Public (the people who we're trying to get water and sanitation to.)
Note that in this schema, Akvo is actually a Support Partner. I think that's an interesting angle to take when explaining the system to people in future.
Trust is money is life
The Akvo Really Simple Reporting (Akvo RSR) component of the Akvo system is designed to reduce the risk of money leakage to a level low enough that it ceases to concern the funding public and funding partners or substantially harm the field public.
This is an important definition. Integrated Pest Management is about the most successfully generally deployed example of real world whole systems thinking, and it starts with defining an "acceptable pest level." Similarly, we need an acceptable fraud level: something like "less than one failed project."
So our goal is to reduce the leakage of money as it travels between the funding public and the field public to below the level where a single project fails because of dishonesty.
Frauds should be detected early enough to be prevented before projects cannot go ahead because the money is gone, and in cases where this cannot be arranged, a clean hand-off of the situation to relevant legal authorities is probably what the funding public expects, and what the field public has a right to.
This is important because it clearly defines the goal of the system: to move money safely, to detect leaks swiftly while the bulk of the funds are still safe, and to store data useful for fighting off wrongdoers. Fraud is the specific focus of this analysis, but incompetence is a larger, realer risk in most cases. However, the system which detected hardened attackers should catch clowns too.
The Trust Chain is like a Cold Chain
Funding Public -> Funding Partner -> Akvo Marketplace -> Field Partner / Support Partner -> Field Public.
- Funding Partners trust Akvo to select appropriate Field Partners and Support Partners.
- Akvo trust the Funding Partner to select Field Partners appropriate to their goals. If you want to fund fighting malaria, and you're funding water and sanitation, wrong goal, wrong partner. This is an important question in terms of funding partner expectations of field partners - not getting quite the expected result can be misinterpreted as a security problem when, in fact, it's a problem around setting shared goals.
While Akvo takes responsibility for reporting the actual success of the enterprise requires the trust chain to be preserved across many entities we do not have administrative control over. This is a critical issue to understand as the technology is being designed.
The Phone Link
The job of the Akvo Phone is to ensure one link on the Trust Chain is reliable: Akvo RSR.
Akvo RSR is there to do one thing: accurately report all relevant field conditions.
This is a complex statement. Accurately meaning without distortion. All relevant is harder, because what people do not choose to report can be just as important as what is reported. There is an implicit gap here, and one which we cannot realistically hope to get around: what people do not show you is often where the problem lies.
So let us restate the problem in a more soluble form.
Akvo RSR's goal is to enable a trusted third party to make a field report in a way which is beyond credible technical challenge.
This means that a doubtful person can verify that what is in the field report - at least the pictures and video - is reliably of the place, time and project indicated.
A secondary goal is that an untrusted person - who we might believe we can trust - should be as constrained as is reasonable in the problems they can cause us by reporting bad data. We cannot stop them not showing us what is important, but we would like to stop them causing us to believe things which are not true by sending false pictures and video.
It's important to put these two goals in the context of the trust chain. One of the few links we can hope to strengthen through technical measures is the link that goes through the mobile phone.
Security Modeling the Phone
The phone has seven salient properties for our work.
inputs
- camera (still and video)
- microphone
- GPS
- built-in software
- custom software
- data connection to the outside world
- SIM card
We have no control of the following factors
- built-in software
- SIM card security
- GPS security
- availability of data connection in any given place
We can pick a friendly platform, but we cannot meaningfully protect the phone against operating system level hacks like jailbreaks. Nor can we meaningfully protect device configuration without moving to tamper-resistant hardware.
There are some simple tamper-resistance measures we could take, like using tamper evident labels, which are cheap and often reasonably effective. This may be an area to investigate in subsequent years.
It is possible that, with cooperation from the phone operators, we could get access to the public key encryption facilities of the phone SIM card. This would significantly extend the security of our operations on the phone, and may be worth investigating. I do not know whether standard phone APIs allow access to the public key on the SIM card for signing arbitrary data.
The SIM card is designed not to allow the Ki to be obtained using the smart-card interface. Instead, the SIM card provides a function, "RUN GSM ALGORITHM", that allows the phone to pass data to the SIM card to be signed with the Ki.
http://en.wikipedia.org/wiki/Subscriber_Identity_Module#Authentication_key_.28Ki.29
In the long run this may turn out to be the hot tip.
Security Modeling the Environment
There are five factors in the environment.
- the person operating the Phone, our Trusted Representative
- the trusted parties of the Village (our Trusted Field People)
- the physical stuff we are shown by the phone user ("on stage")
- the physical stuff we are not shown by the phone user ("off stage")
- the person being shown the images (the "data consumer.")
The Idealized Interaction
What we would like to do (something like) this:
1> have a Trusted Party, who is Actually Worthy Of Trust, go to a Project Site.
2> they stand around all the relevant objects and put them "on stage" by taking pictures of them. there are multiple angles of each vital object.
3> all of these pictures include happy, smiling Trusted Field People who are already in our database of pictures.
4> all pictures are GPS-tagged on the phone and SIM-signed, proving the device they were taken on was at the location given, within the constrains of the phone's hardware.
5> the phone is checked periodically for signs of tampering.
6> critical objects are completely recognizable.
7> pictures are part of a consistent, coherent timeline.
8> multiple pictures are taken of objects, with good angle and of the right details
The Fraud Threat Model
There are three basic threats which the phone part of the trust chain can guard against if used in the Idealized Interaction.
In the Idealized Case, the completed well is proven beyond all reasonable doubt to exist at the GPS coordinates shown on the pictures, to have been completed to the satisfaction of the village elders concerned, and so people further up the Trust Chain can feel confident that their investment was successful.
Here are the three threats this model effectively answers.
1> Passing off a well in another place for the well that was supposed to be built. (GPS)
2> Completing the work in a shoddy fashion. (face checks are here because pictures of objects may not be enough to verify that the locals are happy with the results - this is the local review on film, basically.) Also, if the pictures are of sufficient quality, a lot can be read from these by an expert working at the support partner.
3> Presenting a fake well for a real one. For example, building a mud-brick wall and pump, and pumping water from a bucket. Looks like a well, works like a well, but you put it all back in the truck afterwards.
We don't just want to see the well and the well operating, we want a variety of third parties to have their happiness at the completion of the project verified. Really we want to see smiles and laugher _as part of the security process_ because if they're not happy with the work done on their behalf, something is wrong. It might not be a security issue, but it's a problem somewhere on the trust chain.
The Technical Threat Model
1> Altering pictures using photoshop
2> Taking pictures of one thing or one place and passing them off as another. ("another well vs. the well we paid for")
3> Moving pictures in time (showing an old well)
All of these threats are countered by affixing security metadata to pictures when they are taken, including GPS data. We may also discover there is milage in digitally signing pictures in the camera over the network (even using SMS) to effectively datestamp them so there is no time to modify them. This is a little tricky as a security feature because we still have to deal with somebody pushing pictures on to the camera from a third source using, say, bluetooth transfer, and then having the application sign them.
Conclusion is probably that the application needs to have direct, low-level access to the camera and ideally to the SIM card. Even getting an audit chain to a specific camera user might be helpful in general fraud protection.
The Use Threat Model
The fully trusted and untampered camera is used to take pictures of staged scenes. 419 scams often incorporate a lot of very serious efforts to convince people that what is real is what is not, and we're protected by the small amounts of money moving through the system at this point, but if we scale these issues may begin to affect us more seriously.
Useful Technologies
1> facial biometrics to identify trusted third parties in scenes, like village elders who are photographed carefully at project inception.
2> independent, third party data from things like satellite imagery vendors.
3> out-of-band security tokens, like the SecureID devices which have a psuedorandom number generator on a keychain-sized tamper-resistant device.
4> tamper-evident stickers.
5> tamper-evident phone hardware.
6> phone CCD noise floor analysis (where the characteristics of a given CCD chip are used to verify that pictures were taken from it by analyzing patterns of noise.) This is spook territory, but there are some public papers on it.
7> PROTOCOLS PROTOCOLS PROTOCOLS - careful design of how we put the phones into the business process so we get them to do what they can do - "prove X was done at Y by date Z" and not what they cannot do - "reassure us everything is OK at village Y." We have to be very clear and specific about what we think we can prove, and that's a protocol design issue.
8> public key cryptography
9> access to the SIM-card based PKI infrastructure
10> secured phones (i.e. are the hardware companies doing anything useful?)
11> crowdsourced imagery - what happens if everybody in the village takes pictures and uploads them to RSR at the end of the project, rather than just one person? Twenty or thirty phones, two or three images each, now we have collectively-sourced proof of an event's occurrence.
12> "Wiggle" 3D photography http://www.well.com/user/jimg/stereo/stereo_hearth.html
13> 2D barcodes (for example, attached to equipment sent into the field, or to specific completed projects, or to auto-insert images into specific projects if used as a "clapper board" like in the movies)
Protocol Design
SMEP - Secure Metadata Enhanced Photography
Ideally many devices, applications and networks would standardize on a protocol for moving around these authenticate, credentialed pictures and videos. Conceiving of this as a protocol design situation, rather than simply creating an application, provides a rational way to proceed as the technologies mature and spread across devices and organizations.
The goal is to move towards a situation where many devices and platforms, with a range of degrees of trust, can interchange SMEP objects pinning the metadata, degree of trust in the metadata, and the actual captured image together as a single cryptographically managed unit, perhaps including chain of custody and authentication data, provenance and so on.
A plausible format for these objects would be XML with enclosures, although fixing the metadata into the EXIM fields on the imagery would also be a useful path to investigate.
