[Ssc-dev] InformaCam: a question about "genuine-ness" of an InformaCam image

Tue Oct 1 02:07:25 EDT 2013

Thanks Nathan this great. Speaking of blog posts, with a little tweaking
this email thread would make a good one. Let me know if you want me to help
out with that.
On Sep 30, 2013 11:07 PM, "Harlo Holmes" <harlo at guardianproject.info> wrote:

> Couldn't have laid it out better myself.  Thanks, Nathan!
>
> ++++++++++++++++++++++++++
> Research Fellow, Head of Metadata
> The Guardian Project <https://guardianproject.info>
>
> pgp: 0xA4469630
> twitter: @harlo
>
>
> On Mon, Sep 30, 2013 at 12:58 PM, David Oliver <david at olivercoady.com>wrote:
>
>> I agree that what we seem to have are "malicious user scenarios" and I
>> think it will be good to document those.  That, alongside a documented
>> technical "trail" from capture to receiver-side verification should blunt
>> many of the challenges casual parties will perceive.  I think it's also a
>> firm starting point for the IBA, who will indeed be testing both technical
>> and human maliciousness in court...an evolving process.
>>
>> Thanks for this, Nathan.
>>
>>
>> David M. Oliver | david at olivercoady.com | http://olivercoady.com |
>> http://dmo.tel | @davidmoliver | +1 970 368 2366
>>
>>
>> On Mon, Sep 30, 2013 at 12:34 PM, Nathan of Guardian <
>> nathan at guardianproject.info> wrote:
>>
>>>  On 09/24/2013 04:02 PM, David Oliver wrote:
>>>
>>>  With IBA getting ready to openly discuss eyeWitness I was reminded of
>>> a question Eric Johnson (Internews) asked at the Martus training:
>>> "How can we ACTUALLY know the image is genuine?" about the validity of
>>> an image in InformaCam.
>>>
>>> I've cc'd the dev list, since I think is an important discussion to have
>>> with everyone.
>>>
>>> I think we need to come up with standard language with exactly how much
>>> we are claiming to achieve with InformaCam. This is not unlike Tor's
>>> unending with challenging on defining how much anonymity they can actually
>>> provide. Often it comes down to deployment details or specific malicious
>>> "bad actor" user stories, but it is necessary to have these well
>>> documented, so we can point to them from the get go, no matter how unlikely
>>> or edge case they might seem to be.
>>>
>>> At a high level InformaCam does not guarantee "This image is real",
>>> since even in an unmanipulated photo you can easily have actors, or staged
>>> props, etc. What InformaCam is attempting to do is say "this picture or
>>> video began its documented existence at X point in time, and here is a
>>> bunch of supporting evidence about its origins". It is up to the
>>> organization receiving it to not blindly trust the data that is is
>>> "genuine", but to use the evidence we provide to more quickly and
>>> efficiently prove that something is what it claims to be.
>>>
>>> Now, the real work is to ensure that process also works if the data
>>> provided has been hijacked, modified or entirely generated from make
>>> believe. So, let's dig into that.
>>>
>>>
>>>
>>>  Working backwards, from a received image:
>>> 1. an image, as a file system entity, can have its hash computed to see
>>> that hash
>>> matches a separately-received hash
>>> 2. J3M extracted from an image was decrypted using a key consistant with
>>> the key with which the J3M was encrypted
>>> 3. J3M contents have timestamp similar to (same as?) captured image
>>>
>>>
>>> Yes, these are all true and provide the most basic level of
>>> verification. This proves that the media was not manipulated by a "man in
>>> the middle" of any sort, and ensure, if that as the evidence is handled
>>> down the line, that there is an initial verified state snapshot to refer
>>> back to.
>>>
>>> In addition, the additional contents of the J3M data provide real world
>>> data points that should corroborate what you are seeing in the media file.
>>> If the data says its 6pm in September in Boston, and the recorded heading
>>> is westerly, do you see the sun starting to set? Do the cellular towers
>>> correspond to a North America carrier? (with help of third-party lookup
>>> service). If I visit the place where the media was captured, do I see some
>>> of the same wifi hotspot SSIDs?
>>>
>>>
>>>  And, probably not important in the "genuine" discussion are these
>>> steps:
>>> 4. image was transfered securely from device to receiver (HTTPS, Tor
>>> optional)
>>>  - in the case of GDrive, GlobalLeaks even adds anonymity
>>> 5. Image file is stored in encrypted storage on the device after
>>> acquisition and before transmission
>>> 6. originally-gathered image is removed from unsecure ("gallery") storage
>>>
>>> Yes, these are additional assurances that the InformaCam stack is doing
>>> its best to defend all participants and content from surveillance,
>>> manipulation, intrusion, retribution and more.
>>>
>>>
>>>
>>>  All good.  But, this is a pointless exercise in answering Eric's
>>> question as any party can:
>>> (1) use any available tool to capture and possibly doctor an image
>>> before "ingesting" into InformaCam
>>>
>>> So this is where the "take a boring picture" part comes into play. When
>>> you do this, you submit a number of base frames (along with your public
>>> key) to who ever it is that you are planning to submit media submission to.
>>> Using a fairly well known, though not simple, back end process, that can be
>>> done to compare the base frames against the signature of submitted media,
>>> to check for manipulation and similarity of camera hardware sensor
>>> artifacts.
>>>
>>> This is solving a different, but related, problem than InformaCam. There
>>> are both research, open-source means of doing this, as well as commercial
>>> products:
>>>
>>> "Large Scale Test of Sensor Fingerprint Camera Identification"
>>> http://www.ws.binghamton.edu/fridrich/research/EI7254-18.pdf
>>>
>>> " FourMatch is an extension for Adobe Photoshop that instantly analyzes
>>> any open JPEG image to determine whether it is an untouched original from a
>>> digital camera."
>>> http://www.fourandsix.com/fourmatch/FourMatch: Authenticate images
>>> instantly
>>>
>>>
>>>
>>>
>>>  (2) acquire InformaCam open source and create a PIRATE app that
>>> creates any
>>> imaginable metadata (reads it from a file, both image and file on a PC?)
>>>
>>>
>>>
>>>  (3) insert that metadata into the image in the valid InformaCam way,
>>> including calculating
>>> the hash to assure tamper-resistance.  This image and metadata can be
>>> encrypted using a perfectly valid key received from an entity.
>>>
>>>
>>> In the case of #2 and #3 above, this is definitely a unique issue for
>>> InformaCam... so the image is non-modified, it is taken from the actual
>>> camera, but the supporting sensor metadata is forged. The GPS, compass
>>> data, wifi hotspot, and bluetooth id's, could all be forged if someone
>>> created a malicious app.
>>>
>>> I think we have to dig further to determine exactly what could be
>>> achieved with this sort of malicious use:
>>>
>>> 1) ATTACK: An event could be documented at the correct location and
>>> time, but time stamped in J3M for a different day.
>>> DEFENSE: this is why the Notary feature is important, such that we
>>> correlate when the hash of the file was received, vs when the J3M says it
>>> was created.
>>>
>>> 2) ATTACK: the GPS and compass coordinates are forged to show something
>>> happening somewhere it is not.
>>> DEFENSE: it is essentially we find a way to easily double check details
>>> such as GPS, compass, cell towers, etc to make sure they all verify both in
>>> data, and visually... perhaps we can easily use Google Street View where it
>>> exists, and otherwise, an organization could have investigators who return
>>> to the scene of the crime to verify.
>>>
>>> I won't go on here, but I think we should tackle these types of
>>> ATTACKS/DEFENSES soon and write them all down on the wiki, as a start.
>>>
>>>
>>>
>>>  Also, harder to do but perfectly possible to move this process to the
>>> device itself
>>> reading any imaginable image out of the unsecure image gallery and then
>>> repeat process.
>>>
>>> I don't think it is any harder to do from the app itself, then from a
>>> desktop. It is the same, and perhaps easier, since our code exists already
>>> for an Android app.
>>>
>>> We could possibly look into maintaining our code open-source, but
>>> somehow using app DRM or other unique build-time keys, to help ensure that
>>> a valid client app is actually being used.
>>>
>>>
>>>
>>>  Result: un-genuine image said to be genuine.
>>>
>>>  Can we use the idea of "technical mischief" vs "human mischief"?  That
>>> is
>>> can we get this right for all cases EXCEPT the case that the human
>>> (actual user of the
>>> app) decides to create mischief?
>>>
>>> Yes, but I think we can go a long way to defend against humans as well.
>>>
>>>
>>>
>>>  Is it going to be important for IBA to lay out failure cases?  Or, are
>>> we simply going to use the failures we discover to refine the app?
>>> On this score, is "partial guarantee to be genuine" valuable, or is this
>>> going to devolve into "there is no partly-genuine option"?
>>>
>>>   Again, the goal is to provide enough supporting evidence that can be
>>> trusted such that reporters, investigators, prosecutors, defenders, etc,
>>> have a starting point they can trust. Today, they have nothing except for
>>> the pixels they see, and perhaps a few words in a blog post, youtube
>>> description, email or tweet. Your questions is spot on in putting the
>>> burden on us to ensure that our users can trust the additional proof points
>>> they are given, and that all of the value of InformaCam is not hijacked by
>>> bad actors.
>>>
>>> I hope my response is a useful response to your and Eric's questions,
>>> and as I said, we should ensure this is formally documented and tackled. If
>>> we can also design additional features for a v2 roadmap, or come up with a
>>> set of "Other Tools You Should Use" for v1, that would be fantastic.
>>>
>>> +n
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> Ssc-dev mailing list
>>
>> Post: Ssc-dev at lists.mayfirst.org
>> List info: https://lists.mayfirst.org/mailman/listinfo/ssc-dev
>>
>> To Unsubscribe
>>         Send email to:  Ssc-dev-unsubscribe at lists.mayfirst.org
>>         Or visit:
>> https://lists.mayfirst.org/mailman/options/ssc-dev/harlo.holmes%40gmail.com
>>
>> You are subscribed as: harlo.holmes at gmail.com
>>
>>
>
> _______________________________________________
> Ssc-dev mailing list
>
> Post: Ssc-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/ssc-dev
>
> To Unsubscribe
>         Send email to:  Ssc-dev-unsubscribe at lists.mayfirst.org
>         Or visit:
> https://lists.mayfirst.org/mailman/options/ssc-dev/bryan.nunez%40gmail.com
>
> You are subscribed as: bryan.nunez at gmail.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/ssc-dev/attachments/20131001/c04eede3/attachment-0001.html>