13:55:55 <abstractj> #startmeeting
13:55:55 <jbott> Meeting started Tue Oct  8 13:55:55 2013 UTC.  The chair is abstractj. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:55:55 <jbott> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:55:56 <passos> mmusaji: Follow http://aerogear.org/docs/guides/GetStartedAndroidEclipse/
13:56:00 <abstractj> #chair matzew qmx cvasilak corinnekrych abstractj
13:56:00 <jbott> Current chairs: abstractj corinnekrych cvasilak matzew qmx
13:56:11 <abstractj> #link http://oksoclap.com/p/iOS_Meeting_(Security)
13:56:57 <cvasilak> #topic iOS Security Bootstrap Meeting
13:57:13 <abstractj> #action focus on the algorithms already provided by Common Crypto
13:57:13 <abstractj> #action start to link Jiras into AGSEC-114 (For an example see: https://issues.jboss.org/browse/AGSEC-115 )
13:57:20 <abstractj> #action fork and update the gist sent to aerogear-dev
13:57:20 <abstractj> #link https://gist.github.com/abstractj/f1229ae075f8e6688c75
13:57:22 <abstractj> #action add/change these scenarios as needed. But think about what is doable to do 'til mid November
13:57:24 <jbossbot> jira [3AGSEC-114] Provide easy to use cryptography interface [10Open (Unresolved) Feature Request,7 Major,6 Bruno Oliveira] https://issues.jboss.org/browse/AGSEC-114
13:57:24 <jbossbot> jira [3AGSEC-115] Symmetric encryption support [10Open (Unresolved) Sub-task,7 Major,6 Bruno Oliveira] https://issues.jboss.org/browse/AGSEC-115
13:57:24 <abstractj> #action focus on the algorithms already provided by Common Crypto
13:57:27 <abstractj> #action start to link Jiras into AGSEC-114 (For an example see: https://issues.jboss.org/browse/AGSEC-115 )
13:57:36 <abstractj> #action fork and update the gist sent to aerogear-dev
13:57:36 <abstractj> #link https://gist.github.com/abstractj/f1229ae075f8e6688c75
13:57:38 <abstractj> #action add/change these scenarios as needed. But think about what is doable to do 'til mid November
13:57:44 <jbossbot> jira [3AGSEC-114] Provide easy to use cryptography interface [10Open (Unresolved) Feature Request,7 Major,6 Bruno Oliveira] https://issues.jboss.org/browse/AGSEC-114
13:57:46 <jbossbot> jira [3AGSEC-115] Symmetric encryption support [10Open (Unresolved) Sub-task,7 Major,6 Bruno Oliveira] https://issues.jboss.org/browse/AGSEC-115
13:57:49 <abstractj> feel free to ask questions or whatever
13:57:52 <matzew> abstractj can we iterate in sections ? :)
13:57:59 <abstractj> matzew yeah, go
13:58:01 <matzew> abstractj :)
13:58:04 <matzew> ok, one sec
13:58:47 <matzew> abstractj "focus on the algorithms already provided by Common Crypto" we build ObjC wrappers around the C API they have, right ?
13:59:02 <matzew> abstractj and the algor. we start with is GCM
13:59:09 <abstractj> matzew wrapper like we did for Java with BouncyCastle
13:59:14 <abstractj> matzew yeah!
13:59:17 <matzew> yeah, ok - cool
13:59:23 <abstractj> wrappers for CommonCrypto
13:59:37 <abstractj> #info the idea is to provide wrappers for CommonCrypto
13:59:38 <matzew> abstractj I think /cc cvasilak  the CommonCrypto is C; we should perhaps make it a bit more OO, using ObjC ?
13:59:44 <matzew> or am I wrong, cvasilak ?
13:59:46 <abstractj> #info the main goal is to have a easy to use crypto API
13:59:47 <corinnekrych> using AES128 encryption alto abstractj
13:59:47 <corinnekrych> algo
14:00:03 <matzew> abstractj awesome
14:00:16 <abstractj> matzew totally
14:00:19 <matzew> :-)
14:00:20 <cvasilak> matzew: correct, and most of the wrappers that current exist aim to provide a OO wrapping of the C interface
14:00:27 <abstractj> corinnekrych if possible AES256
14:00:41 <matzew> abstractj since there is no ECC support in CommonCrypto (CC) we will look at that later ?
14:00:52 <abstractj> #info feel free to add ideas to that gist
14:01:01 <abstractj> #link https://gist.github.com/abstractj/f1229ae075f8e6688c75
14:01:13 <matzew> abstractj sure :-) just trying to get my head around it :-)
14:01:20 <matzew> abstractj kinda borrowing your brain
14:01:23 <matzew> ?security
14:01:29 <abstractj> matzew yeah later, or major goal is how to properly store the keys and encrypt the data
14:01:36 <abstractj> matzew is important but not a deal breaker
14:01:47 <matzew> abstractj so GCC , the semetric one is good enough for now
14:02:04 <abstractj> matzew AES + GCM mode yeah
14:02:15 <abstractj> let's start with the bare minimum to move forward
14:02:30 <matzew> abstractj ok - good; at least I think it makes sense :-)
14:02:30 <cvasilak> abstractj: as i understand there are different modes of the AES encryptions , mode CBC and mode GCM need to determine which one is now supported on iOS
14:02:32 <abstractj> make sure to link jiras to https://issues.jboss.org/browse/AGSEC-114
14:02:33 <jbossbot> jira [3AGSEC-114] Provide easy to use cryptography interface [10Open (Unresolved) Feature Request,7 Major,6 Bruno Oliveira] https://issues.jboss.org/browse/AGSEC-114
14:02:59 <matzew> so AES and GCC are prio1 (the ObjC wrappers for CC) followed by wrappers for PBKDF2 ?
14:03:16 <abstractj> cvasilak feel free to add an action my friend
14:03:24 <abstractj> cvasilak and if you need jiras for R&D too
14:03:32 <abstractj> just let me know
14:03:56 <matzew> abstractj speaking of JIRAs: you prefer all items in AGSEC ? Or also reference items in AGIOS ?
14:03:58 <abstractj> matzew yeah, our major goal is to encrypt the whole thing, we can start with symmetric encryption
14:04:26 <abstractj> matzew just file and link like we did for JS https://issues.jboss.org/browse/AGSEC-115
14:04:26 <jbossbot> jira [3AGSEC-115] Symmetric encryption support [10Open (Unresolved) Sub-task,7 Major,6 Bruno Oliveira] https://issues.jboss.org/browse/AGSEC-115
14:04:32 <abstractj> to avoid confusion
14:04:51 <matzew> abstractj ok, makes sense - we did that before; good
14:05:05 <cvasilak> #action cvasilak determine mode of AES encrypt currently provided by the crypto interface, mode CBC or GCM
14:05:47 <abstractj> anything else to this topic? feel free to switch
14:05:54 <matzew> abstractj I think I mixed already some topics :)
14:06:12 <abstractj> matzew np, let's move forward
14:06:20 <cvasilak> #topic Asymmetric encryption with Elliptic Curve Cryptography (ECC)
14:06:24 <cvasilak> #info required but can be postponed atm (still necessary and completely important)
14:06:25 <cvasilak> #info required because we will stablish a key agreement with the server
14:06:51 <abstractj> #info if for some reason ECC is not supported on iOS, the plan B might be RSA with Diffie Hellman
14:06:53 <abstractj> #link  https://developer.apple.com/library/ios/samplecode/CryptoExercise/Introduction/Intro.html (must be checked)
14:06:56 <matzew> I think that is a "tough" one; since there is not really much
14:07:08 <matzew> abstractj yeah; the research from cvasilak showed the same
14:07:10 <abstractj> matzew we will get there
14:07:11 <matzew> :-)
14:07:19 <cvasilak> :)
14:07:49 <cvasilak> #topic Cryptographic Hash Functions
14:07:49 <cvasilak> #info priority 3
14:07:53 <matzew> abstractj I am totally +1 on moving the ECC a bit; due to complexity; but looks like we already said that on the first topic
14:08:15 <abstractj> matzew yeah, but np. It must be clear to the whole team
14:08:27 <matzew> abstractj yeah, sure :) "security is hard"
14:08:41 <matzew> I noticed again, when syncing up on it :-)
14:08:52 <corinnekrych> something you also mentioned abstractj  is to start without server side key, right
14:08:58 <abstractj> any questions about hashing?
14:09:01 <matzew> abstractj yep
14:09:09 <matzew> one sec
14:09:23 <abstractj> corinnekrych yeah, working on it with key stores. But that should not be a deal breaker to move forward
14:09:28 <matzew> SHA is efficient enough ? and it's good enough to that that as P3 ?
14:09:45 <abstractj> corinnekrych look at the diagram 2, please
14:09:56 <corinnekrych> where about abstractj ?
14:09:58 <abstractj> corinnekrych is possible to generate the keys locally, store them and encrypt for iOS
14:09:58 <corinnekrych> here https://gist.github.com/abstractj/f1229ae075f8e6688c75
14:10:05 <abstractj> the key exchange can be done later
14:10:09 <abstractj> corinnekrych yup
14:10:33 <corinnekrych> yep
14:11:02 <abstractj> matzew SHA-256 is the minimum to the Java bits and JS
14:11:08 <matzew> ah, the hashing is also already in CC
14:11:32 <abstractj> #info SHA-256 is the minimum to the Java bits and JS
14:11:32 <matzew> abstractj so same plan: ObjC wrappers
14:11:37 <cvasilak> matzew: correct they already provide an interface to it
14:11:39 <abstractj> matzew exactly
14:11:54 <abstractj> if we possible to make simple to our devs, we win
14:12:02 <matzew> abstractj cvasilak but we argree on doing ObjC (OO-style) wrappers for the C functions, right ?
14:12:08 <abstractj> s/if we/if
14:12:08 <matzew> abstractj +1
14:12:53 <cvasilak> everyone is ok should we move on?
14:12:59 <abstractj> matzew I'm not an ObjC specialist, but I assume you are correct about wrappers
14:13:02 <abstractj> cvasilak do it
14:13:12 <qmx> yup
14:13:37 <matzew> abstractj we will assist  :-)
14:13:42 <abstractj> matzew assist on what?
14:13:45 <cvasilak> #topic Digital Signatures
14:14:00 <matzew> abstractj the ObjC
14:14:09 <corinnekrych> about wrapping OO style interesting reading on cvasilak's book on wiping memory matzew
14:14:13 <abstractj> matzew to be clear, I don't have time to implement the whole thing, that's the reason why I really need help with it
14:14:29 <jbossbot> new jira [3AEROGEAR-1327] move ag-controller-demo to jax-rs [10Open (Unresolved) Feature Request,7 Major,6 Unassigned] https://issues.jboss.org/browse/AEROGEAR-1327
14:14:30 <matzew> abstractj ah, ok :-) so it's the other way around :)
14:14:44 <abstractj> cvasilak sorry, go for it
14:14:48 <matzew> abstractj glad we talked :-)
14:15:20 <cvasilak> #info priority 3 - The plan is to have signed http request
14:15:57 <cvasilak> as i see its provided by Security framework
14:16:09 <cvasilak> not the CommonCrypto
14:16:09 <abstractj> cvasilak so if it's easy, I'm fine on changing priorities
14:16:14 <matzew> cvasilak that is cool - it's already ObjC
14:16:33 <abstractj> if not, we can see as priority 3
14:16:58 <abstractj> I'm fine with what you guys think is better and healthy
14:17:08 <jbossbot> git [12aerogear-controller-demo] push 10master7 f400a9e.. 6Bruno Oliveira Note about ag-controller support
14:17:08 <jbossbot> git [12aerogear-controller-demo] push 10master7 91c3ec9.. 6Daniel Passos Merge branch 'note'
14:17:11 <jbossbot> git [12aerogear-controller-demo] push 10master URL: http://github.com/aerogear/aerogear-controller-demo/compare/a86432e...91c3ec9
14:17:13 <matzew> abstractj cvasilak corinnekrych I think it's similar "easy" to the other items - we do wrappers
14:17:41 <matzew> I do think that Digital signatures might be a bit simpler, since there is already an OO-ish API on the framework
14:17:49 <matzew> abstractj do we already have (for JS/Java) a proposed API for the Digital Signatures ?
14:17:58 <abstractj> matzew cvasilak corinnekrych I will trust in your judgment, feel free to pick and file any jiras as needed
14:18:24 <abstractj> matzew yeah, ECDSA. Must be implemented for Java, but was already implemented in JS
14:19:25 <matzew> abstractj ah, ok - let me check that JS API; so would be make sense if the ObjC 'wrapper' follows that - as close as possible
14:19:35 <abstractj> matzew check the gist please, is up to date
14:19:55 <matzew> abstractj sweet! thanks - looks good
14:20:43 <travis-ci> [travis-ci] aerogear/aerogear-controller-demo#51 (master - 91c3ec9 : Daniel Passos): The build passed.
14:20:43 <travis-ci> [travis-ci] Change view : https://github.com/aerogear/aerogear-controller-demo/compare/a86432e70d2b...91c3ec90cb97
14:20:47 <travis-ci> [travis-ci] Build details : http://travis-ci.org/aerogear/aerogear-controller-demo/builds/12276487
14:20:48 <proddbot> Functional Test added -- https://github.com/aerogear/aerogear-controller-demo/pull/51 is closed
14:20:48 <jbossbot> git pull req [12aerogear-controller-demo] (7closed) 6tolis-e Functional Test added11 https://github.com/aerogear/aerogear-controller-demo/pull/51
14:20:52 <smikloso> passos|brb: ping
14:20:59 <abstractj> great, as I told to you guys is important to fork that gist and add your ideas and suggestions for ObjC
14:21:30 <smikloso> passos|brb: i got it work http://pastebin.com/raw.php?i=zEpdrLH8
14:21:42 <abstractj> anything else?
14:21:51 <qmx> nope
14:22:08 <smikloso> passos|brb: but just partially, the problem is that it seems android is requesting bad endpoint
14:22:12 <cvasilak> #topic Public-Private Key-Pair
14:22:13 <matzew> not on digital signatures
14:22:16 <matzew> ah :-)
14:22:34 <cvasilak> again commoncrypto provides the relative functionality
14:22:37 <abstractj> cvasilak I think this topic was covered by asymmetric encryption
14:22:48 <abstractj> but feel free to ask if necessary
14:23:13 <smikloso> passos|brb: when i got it right endpoint for controller demo is /otp but android demo app is requesting /otpuser which is obviously wrong, i tried to rename OTPUser class to OTP and it indeed requests /otp but the result is the same ...
14:23:17 <cvasilak> abstractj: nope I am ok added for completeness, ok moving forward
14:23:25 <cvasilak> #topic Password-based key derivation (PBKDF2)
14:23:44 <abstractj> #info priority 2 in my opinion, because is possible to use PBKDF2 with AES for example for encryption
14:23:45 <cvasilak> #info priority 2 in my opinion, because is possible to use PBKDF2 with AES for example for encryption
14:23:50 <abstractj> cvasilak ooops sorry
14:23:55 <cvasilak> :)
14:24:12 <cvasilak> common crypto provides the functionality here too
14:24:17 <abstractj> sweet
14:24:40 <matzew> abstractj cvasilak PBKDF2 with AES -> good enough, for now ?
14:24:54 <corinnekrych> abstractj: what are the use case for derived key
14:25:14 <qmx> corinnekrych: the use case is preventing brute-force attacks
14:25:21 <abstractj> corinnekrych when the user input the password, it must have some entropy to generate the keys
14:25:23 <corinnekrych> how would it fit in our workflow
14:25:23 <cvasilak> abstractj: as I understand and correct me if am wrong PBKDF2 (among other uses) will encrypt the generate private key right?
14:25:28 <abstractj> otherwise shit like qmx said happens
14:26:31 <abstractj> cvasilak correct, you can use it to generate the key or just automatically generate with no PBKDF2
14:27:16 <abstractj> this is important because at some point we will provide a way to user input the password, and this will be responsible for generate the keys
14:27:28 <abstractj> so use it in combination with our first topic, is a nice idea
14:27:40 <abstractj> corinnekrych makes sense?
14:28:04 <matzew> abstractj with GCM ?
14:28:13 <corinnekrych> yep abstractj I've also read some use cases like: sharing the same data among users etc...
14:28:18 <abstractj> matzew yup
14:28:45 <abstractj> corinnekrych revisit that gist and feel free to send me questions on the ML
14:29:13 <abstractj> it must be a concept clear to everyone, we are doing crypto for humans
14:29:13 <corinnekrych> that's why I was asking
14:29:18 <corinnekrych> will do abstractj
14:30:05 <matzew> abstractj yeah, I might ask same/similar questions in the (near) future :)
14:30:23 <abstractj> matzew np at all
14:30:51 <abstractj> next?
14:31:07 <cvasilak> #topic Encryption of storage
14:31:20 <cvasilak> #info Built into iOS - Data Protection (cons: Requires pass-code set by the user)
14:32:26 <corinnekrych> as cvasilak said will work only if passcode is set on in settings
14:32:32 <abstractj> #info Protection classes:
14:32:33 <abstractj> #info Complete Protection -> (NSFileProtectionComplete):
14:32:33 <abstractj> #info Protected Unless Open -> (NSFileProtectionCompleteUnlessOpen)
14:32:33 <abstractj> #info Protected Until First User Authentication -> (NSFileProtectionCompleteUntilFirstUserAuthentication)
14:32:33 <abstractj> #info No Protection -> (NSFileProtectionNone)
14:32:40 <matzew> abstractj cvasilak corinnekrych that's a little bit "funny" due to pass-code requirement
14:32:59 <abstractj> cvasilak I'm not sure about the amount of complexity behind to implement it, so please ignore me if I'm saying some nonsense
14:33:25 <abstractj> cvasilak I would say, provided methods to devs choose whatever protection they want and forbid "No protection"
14:33:47 <abstractj> maybe classify it in 3 levels of security
14:33:57 <abstractj> full, medium, low
14:34:07 <matzew> abstractj sounds like a reasonable idea - also the underlying API is already familiar w/ iOS guys
14:34:16 <matzew> so supporting (at some point) would make sense
14:34:40 <matzew> and our doc would/should :-) be clear on the pass-code requirement
14:34:42 <abstractj> and if for some reason someone specify "No protection", destroy their mobile device
14:34:45 <abstractj> :)
14:35:05 <abstractj> #agreed
14:35:19 <abstractj> once you guys add your ideas there, I'm planning to start a branch at aerogear.org
14:36:42 <corinnekrych> so if we remove no protection it' a one-to-one mapping with NSFile* level
14:37:03 <corinnekrych> for high/medium/low
14:37:06 <matzew> corinnekrych +1
14:38:30 <abstractj> corinnekrych I guess so
14:38:38 <abstractj> cvasilak are you fine with it?
14:39:13 <corinnekrych> then as noted by cvasilak it's an implication by DataStore
14:40:04 <abstractj> #info we can provided methods to devs choose whatever protection they want and forbid "No protection". Providing 3 levels of security ONLY IF possible
14:40:19 <abstractj> #info otherwise just let developers choose whatever they want and take their chances
14:40:48 <corinnekrych> I wonder why there is not AGPListPropertyStore (File protection I guess) and AGMemoryStore ?? cvasilak
14:41:23 <cvasilak> abstractj: corinnekrych one sec
14:41:34 <abstractj> #action cvasilak corinnekrych figure out if the insane protection levels suggested by abstractj are doable. But not an uber priority
14:41:36 <matzew> corinnekrych was not in mind at the time of getting the initial impl. out
14:42:03 <matzew> corinnekrych we can add that; I guess that's part of the crypto meeting / efforts
14:43:10 <abstractj> next?
14:43:33 <matzew> yo
14:43:59 <corinnekrych> you're right matzew it's not in abstractj initial gist
14:44:06 <abstractj> corinnekrych is the reason why I need your smart brain forking it and editing
14:44:12 * abstractj has no brain
14:44:24 <corinnekrych> :)
14:44:36 <abstractj> #topic SQLCipher
14:44:45 <abstractj> #info: sqlcipher has some compatibilty issues, but I'm completely fine if you guys think that's the way to go
14:44:56 <abstractj> #link: https://groups.google.com/forum/#!msg/sqlcipher/A2CcSyDZKPc/erq_45j0EC8J
14:44:56 <abstractj> #info abstractj is not against it, just must be checked
14:45:02 <abstractj> #info https://www.owasp.org/images/5/56/OWASP_ChapterMeeting_SqlCipher-2012.pdf
14:45:22 <abstractj> if we are planning to use it, that would undo the whole action around encrypted storage and currently sqlcipher only supports symmetric encryption
14:45:48 <abstractj> I've been tracking sqlcipher for months, a nice project but like any C dependent project has issues
14:45:48 <abstractj> so is up to you to try or not
14:46:41 <matzew> abstractj " undo the whole action around encrypted storage" - you mean the previous "Providing 3 levels of security" ? (NSFile*)
14:47:27 <abstractj> matzew yeah if you guys choose sqlcipher, because would exist overlappings
14:47:52 <corinnekrych> I wonder if it integrate with fmdb
14:47:53 <abstractj> matzew for example symmetric encryption with AES GCM and symmetric encryption from sqlcipher
14:48:05 <matzew> abstractj hrm; but the previous options could be added on AGPList / AGMemStorage, right ? /cc cvasilak corinnekrych
14:48:18 <matzew> corinnekrych that is another good questions - that's our internal SQLite lib
14:48:25 <abstractj> I won't be against it, is just my impression and I'm open to what you guys think is the best to the project
14:48:28 <cvasilak> matzew: right
14:48:55 <corinnekrych> i think we need to investigate/test further on that
14:49:05 <matzew> cvasilak right in terms of: maybe…. use sqlcipher for SQLite and the other options for PList/Mem etc ?
14:49:29 <abstractj> add an action
14:50:30 <corinnekrych> #action corinnekrych to investigate of SQLite with sqlcipher vs other option for pList/Mem
14:50:30 <cvasilak> matzew: for the question you have about applying NS* to the PList file
14:50:42 <matzew> cvasilak thanks
14:51:07 <matzew> next ?
14:51:15 <matzew> I guess the misc section can be skipped - it's just some links...
14:51:27 <abstractj> anything else?
14:52:04 <matzew> nope
14:52:11 <cvasilak> i am ok  let's starts by the initial actions items (and JIRAs)
14:52:20 <matzew> #agreed
14:52:27 <abstractj> corinnekrych qmx ?
14:52:40 <corinnekrych> i'm fine
14:52:51 <corinnekrych> #agreed
14:52:51 <abstractj> #endmeeting