[Ssc-dev] Authentication, Authorization and Architecture

Hans-Christoph Steiner hans at guardianproject.info
Thu Mar 7 13:15:12 EST 2013 

I found the webcast that nathan posted to be quite informative to this
discussion.  I made an mp3 of it for subway listening.  The slides it the
webcast were not worth much.

http://dl.dropbox.com/u/4794242/Mobile_Evidence_Movie.mp3

here's the original URL:
https://www.sans.org/webcasts/mobile-evidence-modern-e-discovery-risks-techniques-opportunities-95990

.hc

On 03/06/2013 10:23 PM, barbra wrote:
> sure.
> 
> On Wed, Mar 6, 2013 at 10:21 PM, Lee Azzarello <lee at rockingtiger.com> wrote:
> 
>> 15 or 14?
>> On Mar 6, 2013 10:00 PM, "barbra" <blmack at gmail.com> wrote:
>>
>>> i can do 16:00 gmt.
>>>
>>> -barbra
>>>
>>> On Wed, Mar 6, 2013 at 9:57 PM, Lee Azzarello <lee at rockingtiger.com>wrote:
>>>
>>>> I think sooner.  Considering its 10 pm est and timezones, how is 16:00
>>>> gmt?
>>>>
>>>> Lee
>>>> On Mar 6, 2013 9:46 PM, "Harlo Holmes" <harlo.holmes at gmail.com> wrote:
>>>>
>>>>> let's do another call tomorrow to go over these things. any time good
>>>>> for you all?
>>>>> On Mar 6, 2013 9:42 PM, "barbra" <blmack at gmail.com> wrote:
>>>>>
>>>>>> hi
>>>>>>
>>>>>> some of what lee is proposing has come out of a discussion about how
>>>>>> we can have a secure API and more complex authorizations. The API-focus is
>>>>>> coming out of a few different needs:
>>>>>>
>>>>>> 1. IBA wants to seperate the file storage system from the
>>>>>> intake/verification system between the phone and server. An API way of
>>>>>> communicating between functionality seems like the most elegant way to
>>>>>> modularize (and would allow us to be more flexible on our server front-end
>>>>>> as well as with phone interfaces as well), as this functionality is
>>>>>> currently all intertwined in the existing system.
>>>>>> Out of Lee and my discussion today, it was clear that secure API calls
>>>>>> between these modular systems could be largely based on the work already
>>>>>> done that you mentioned Nathan. The different servers could follow the
>>>>>> same/similar verification process.
>>>>>>
>>>>>> 2. IBA is requesting a fair amount of functionality outside of the
>>>>>> scope of InformaCam
>>>>>> (e.g., complex reporting, sharing with external clients, exporting
>>>>>> submitted media, publishing on various outlets, etc.)
>>>>>> Again, an API approach seemed like the best solution with the most
>>>>>> gains. This we also considered OAuth as a good fit for. And it gives us a
>>>>>> ready answer as these types of request will just keep coming...i.e., "yes,
>>>>>> you can get that info through our API and use with x".
>>>>>>
>>>>>> 3. IBA is requesting more complex permissioning for the server-side of
>>>>>> users, as well as more complex evidence logs (and more complex logs are
>>>>>> required in ISO standard for digital repos)
>>>>>> This led us to review SELinux and Fedora Repository which both have
>>>>>> complex permissions engines involved.
>>>>>>
>>>>>> 4. General thoughts have been re-occurring on Guardian and IBA sides
>>>>>> about having a "published" catalog of media derivatives (e.g., to media
>>>>>> outlets, or for people who might be interested, etc.). This is something
>>>>>> that actually Witness already does (though not managed completely with an
>>>>>> IT system). Not a pressing needs, but something to consider as we refactor
>>>>>> the architecture this time around.
>>>>>>
>>>>>> I think Lee can speak to the need he sees with Math folks and the
>>>>>> permission sets.
>>>>>>
>>>>>> But I do think we needed to spend some time deciding how we would
>>>>>> secure our "public-ish" and our internal system API(s), and go about
>>>>>> building some permissions/authorization on the server-side.
>>>>>>
>>>>>> -barbra
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 6, 2013 at 9:20 PM, Harlo Holmes <harlo.holmes at gmail.com>wrote:
>>>>>>
>>>>>>> I think this part of the project refers only to properly
>>>>>>> authenticating IBA staff members as they interact with already-submitted
>>>>>>> media. (like, who on the IBA team has access to view encrypted metadata,
>>>>>>> and keeping logs of who viewed what and when.)
>>>>>>>
>>>>>>> it should be outside the loop we established previously and has
>>>>>>> nothing to do with the mobile client or its users.  But Barbra can explain
>>>>>>> more...
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Harlo
>>>>>>> On Mar 6, 2013 9:03 PM, "Nathan of Guardian" <
>>>>>>> nathan at guardianproject.info> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Lee Azzarello <lee at rockingtiger.com> wrote:
>>>>>>>>
>>>>>>>>> Nathan,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Can you describe the level of detail for authorization of roles from
>>>>>>>>> client to server? I don't think I understand the scope of this
>>>>>>>> project
>>>>>>>>> not the requirements to ensure a chain of custody in a court of law.
>>>>>>>>
>>>>>>>> This is what the entire InformaCam IBA project has been doing for
>>>>>>>> the last year. The Chain Of Custody issue is solved based on the signing
>>>>>>>> and encryption Harlo has already implemented. You should be able to post
>>>>>>>> informacam blobs into the public internet, as long as they have been signed
>>>>>>>> by the submitters key and encrypted to the trusted parties key. We also
>>>>>>>> have the file hash submission process that is again, already designed and
>>>>>>>> implemented.
>>>>>>>>
>>>>>>>> The only roles there were ever meant to be were 1) known or unknown
>>>>>>>> person submitting a report from their device and 2) trusted party receiving
>>>>>>>> report and being able to unpack and verify integrity of report blob.
>>>>>>>>
>>>>>>>> I know we have added additional function to the server to allow
>>>>>>>> searching and browsing of reports, but super complex roles and distributed
>>>>>>>> computing authenticating mechanisms seems like we are way way out of any
>>>>>>>> design goals I am familiar with.
>>>>>>>>
>>>>>>>> Harlo, Bryan - can you provide some clarity here? Are we getting
>>>>>>>> pushed in directions by the IBA that I am not aware of?
>>>>>>>>
>>>>>>>> +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/blmack%40gmail.com
>>>>>>>
>>>>>>> You are subscribed as: blmack 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/hans%40guardianproject.info
> 
> You are subscribed as: hans at guardianproject.info
>

More information about the Ssc-dev mailing list