IRC logs of #tryton for Friday, 2011-08-12

chat.freenode.net #tryton log beginning Fri Aug 12 00:00:03 CEST 2011
-!- dfamorato_(~dfamorato@2001:470:5:71c:3c0d:20fe:9c5d:190f) has joined #tryton02:43
-!- dfamorato(~dfamorato@2001:470:5:71c:3c0d:20fe:9c5d:190f) has joined #tryton03:42
-!- zxq9(~zxq9@FL1-119-244-163-75.okn.mesh.ad.jp) has joined #tryton04:25
-!- yangoon1(~mathiasb@p54B4E5A9.dip.t-dialin.net) has joined #tryton05:02
-!- ikks_(~ikks@190.27.144.25) has joined #tryton05:20
-!- lem0na(~lem0na@95.87.233.210) has joined #tryton08:11
-!- mr_amit(~amit@59.164.85.0) has joined #tryton08:29
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton08:36
-!- okko1(~okko@62.58.29.41) has joined #tryton08:41
-!- nicoe(~nicoe@ced.homedns.org) has joined #tryton09:20
-!- pjstevns(~pjstevns@a83-163-46-103.adsl.xs4all.nl) has joined #tryton09:24
-!- bechamel(~user@cismwks02-virtual1.cism.ucl.ac.be) has joined #tryton09:53
-!- okko1(~okko@62.58.29.41) has joined #tryton09:53
-!- elbenfreund(~elbenfreu@p54B94397.dip.t-dialin.net) has joined #tryton10:18
-!- ccomb(~ccomb@did75-17-88-165-131-42.fbx.proxad.net) has joined #tryton11:37
-!- ikks_(~ikks@190.27.84.116) has joined #tryton12:53
-!- cheche(cheche@46.25.80.67) has joined #tryton13:10
-!- alimon(alimon@187.156.80.54) has joined #tryton15:04
-!- dfamorato(~dfamorato@173-9-190-185-miami.txt.hfc.comcastbusiness.net) has joined #tryton15:31
-!- zodman(~zodman@foresight/developer/zodman) has joined #tryton16:34
-!- pjstevns(~pjstevns@a83-163-46-103.adsl.xs4all.nl) has left #tryton17:02
-!- sharkcz(~sharkcz@2001:15c0:6747:160::7) has joined #tryton17:59
-!- elbenfreund(~elbenfreu@p54B94397.dip.t-dialin.net) has joined #tryton20:33
-!- ccomb(~ccomb@vau75-2-81-57-244-84.fbx.proxad.net) has joined #tryton21:06
-!- reichlich(~reichlich@p578E8BB2.dip.t-dialin.net) has joined #tryton21:18
-!- Ildin(~chatzilla@184-76-111-12.war.clearwire-wmx.net) has left #tryton21:34
-!- Ildin(~chatzilla@184-76-111-12.war.clearwire-wmx.net) has joined #tryton21:34
IldinHas the port for demo2.1.tryton.org been changed to 8000? or should I still be using 8070?21:46
-!- plantian(~ian@c-67-169-72-36.hsd1.ca.comcast.net) has joined #tryton21:48
-!- version2beta(~rob@24.106.58.138) has joined #tryton21:54
cedkIldin: there is no demo2.1 server21:56
IldinOh.21:56
IldinI had just run hg nclone http://hg.tryton.org/tryton/ and the default settings pointed to demo2.1.tryton.org:8000.21:57
IldinMy bad...21:57
Ildin-->(The default settings for the Tryton client.)21:58
cedkIldin: it is the development version22:06
-!- bechamel(~user@host-85-201-144-79.brutele.be) has joined #tryton22:09
version2betaIs anyone here familiar with Yubico yubikeys and maybe Openlab's Yubico module?22:17
version2betaLooking to discuss some security/encryption ideas...22:17
cedkversion2beta: I had taken a look at it22:18
cedkversion2beta: I know the big picture of the design22:18
version2betacedk: Do you think the Yubikey offers potential for use in encryption as well? Application is for secure document management, and the goal is to ensure that only select users are able to decrypt attached files.22:20
version2betacedk: Done this with 1024-bit rsa certs before, but I don't know enough yet about yubikeys to know if they can pass a token that would be usefule.22:21
cedkversion2beta: I don't think22:21
version2betacedk: I figured perhaps not, since they seem to be coming out with a YubiHSM that would be more useful. Price jump from $15 to $500 / user is steep though.22:22
cedkversion2beta: for what I read, Yubikey provides only authentication mechanism22:23
version2betacedk: You know security. If you had to encrypt data (enough information for a high quality identity theft, right down to the credit scores) but make it accessible to, say 3 or 4 people within an organization, any idea what you'd use?22:24
cedkversion2beta: of course it can be used to give access to the documents but the documents will be delivery unencrypted22:24
cedkversion2beta: will you autorise user to get unencrypted documents?22:26
version2betacedk: Not sure I understand the question, but I think the answer is yes. Users will access should be able to retrieve an unencrypted version of the data over an encrypted link (https, for instance).22:27
version2betacedk: Sorry, "users with access"22:27
cedkversion2beta: so a simple authentication on the HTTPS will do the job22:27
cedkversion2beta: with Yubikey if you want22:28
version2betacedk: I don't think that's enough. The immediate application is for a document storage system. I believe the file should be encrypted in the filesystem, and that decryption key should never be present on the filesystem. I try to make it so that a server that's been compromised doesn't allow access to these files.22:29
version2betacedk: Asymmetric encyption. In the current system (not on Tryton) the data is encrypted using a public key, decrypted using a private key stored in memory only while the script is running.22:31
-!- Ildin(~chatzilla@184-76-111-12.war.clearwire-wmx.net) has joined #tryton22:32
cedkversion2beta: this sounds paranoic :-)22:32
version2betacedk: Oh most definitely. ;-)22:32
cedkversion2beta: if you store the data encrypted on the server, you need to be able to get the key to decrypt in some way22:33
cedkversion2beta: so the server could ask to an other host...22:33
cedkversion2beta: wait I have perhaps an idea22:34
version2betacedk: Indeed. On the current system, there's just one key, so it's shared among users who are allowed access. They literally copy and paste it into a field.22:34
cedkversion2beta: you could store the same private key many times but crypted with the password of the user22:34
cedkversion2beta: so when the user query for the document, he must give also his password and the server can decrypt the document on the fly22:35
version2betacedk: Yes - that is the direction I was going. But here's the issue - any user can now decrypt a master key, which gives every user access to every document. I am apparently still more paranoid than you. I figured to assign key pairs to each document repository, and store an encrypted version of the private key for each user who is permitted access.22:36
cedkversion2beta: but I don't think all this prevent the data to be stolen if the server is compromised when running22:37
version2betacedk: Because the assailant can read the private keys from memory?22:37
cedkversion2beta: yes but also he can make man-in-the-middle22:38
cedkversion2beta: or retrieve the document on the network interface when their are send22:38
version2betacedk: In which case, the user needs to also have a key pair, like an X509 certificate22:38
version2betacedk: The document on the wire is encrypted over https...22:39
cedkversion2beta: but the HTTP server have the document unencrypted22:39
cedkversion2beta: also the encryption keys of the https is know by the http server22:39
version2betacedk: Yes, that is true. So an assailant on the machine can have access to each document as it is retrieved.22:40
version2betacedk: How difficult would it be to put openssl decryption into the Tryton client?22:41
cedkversion2beta: I'm not sure it is possible to design a service that will be protected against a assailant that get root access22:41
cedkversion2beta: the Tryton client already uses ssl22:42
cedkversion2beta: and there is fingerprint verfication and you can add ca check22:42
version2betacedk: Of course, I'm sorry. I meant, how difficult do you think it might be to implement X509 certificates in Tryton client so that the user could locally decrypt data received that was encrypted with his or her public key.22:43
version2betacedk: X509 or similar I guess. I'm not sure that the CA is ideal.22:43
cedkversion2beta: you mean that you want the client authenticate to the server with a certificate?22:44
version2betacedk: I can see where that might be a natural addition to the idea, but not what I had in mind. I was thinking in terms of receiving data encrypted with my public key, and decrypting it in Tryton client. Like an email client would do.22:45
cedkversion2beta: ok like gpg22:46
version2betacedk: Perfect. Yes.22:46
cedkversion2beta: don't know if there is python lib to manipulate gpg22:46
version2betacedk: http://packages.python.org/python-gnupg/22:47
cedkversion2beta: yep found it22:47
cedkversion2beta: it is only document or you want to encrypt every data?22:48
version2betacedk: For this project it is only documents.22:49
cedkversion2beta: the attachment?22:49
version2betacedk: Not sure I understand, but yes, I think so. I'd like to pass encrypted files from a URI to the client.22:50
version2betacedk: But they could be stored as Tryton attachments.22:50
cedkversion2beta: ha the data are not stored in Tryton database?22:51
version2betacedk: I think that might be a bad idea. These are 30 - 50 page scans, one or more per repository, 50 or more a day.22:51
cedkversion2beta: in Tryton attachment are stored in the filesystem with just a link from the database22:52
version2betacedk: That might work, but we would need to extend the model to accommodate additional traceability and version control. (I have not looked at the Tryton code, so I'm guessing on this.)22:53
cedkversion2beta: if it is the Tryton server that send the data to the client, I think it is doable to make the server grypt the data with the gpg key of the user and on the client side having a small wrapper that decrypt the data before opening it22:54
cedkversion2beta: and it should be possible to have also the WebDAV services working like that22:54
version2betacedk: The server needs to store it encrypted on the filesystem too, which means it would need to be decrypted before it can be encrypted and sent. I think that has possibility...22:55
version2betacedk: That was cryptic. Sorry. I'll try to explain...22:56
cedkversion2beta: you could store it in a fs that is encrypted22:56
cedkversion2beta: like that if the server hd is stolen, data can not be read22:57
version2betacedk: I think each repository (loan application package, in our case) can have it's own public key, and each user with access to the repository files has a copy of the private key encrypted with their own public key. Does that make sense?22:57
version2betacedk: So when a document is requested, the server sends the client the encrypted private key, gets a decrypted private key back, decrypts the file, encrypts it with the user's public key, and sends it off. Sounds complicated, but it means an attacker on the system can only get it out of memory for a few milliseconds.22:59
cedkversion2beta: yes but I don't see it as an security improvement for the server-side22:59
cedkversion2beta: but I'm not really a security expert :-)23:00
version2betacedk: If the server is live and compromised, without file-based encryption, I don't see how the document itself is secure. I can just copy it off with scp.23:00
version2betacedk: Sorry, I hope I'm not bugging you too much. It's an interesting problem for me :-)23:01
cedkversion2beta: but even with excryption document could be retreived23:01
version2betacedk: With file based encryption, even 1024-bit RSA, it'll take a pretty sophisticated attacker to get anything useful.23:02
cedkversion2beta: once your server is compromised, the attacker could just wait that a user ask for a document and then the attacker can stole the key to decrypt23:02
bechamelwhat about a pure client-side implementation every user as the same public key, the same private key but crypted with different password, and when the client read/save an attahcment the attachement are (de)crupted on the fly, like that only crypted version transit on the network23:02
-!- alimon(alimon@187.156.94.122) has joined #tryton23:02
bechameland the document are never decrypted server-side23:03
cedkbechamel: I guess the issue is to revoke access to someone23:03
bechameland the server doesn't know the keys at all23:03
version2betacedk: The key is only useful for documents in that repository. In our case, three or four documents for one loan application.23:03
bechamelcedk: double encryption ! :)23:03
version2betabechamel: So there's a master key and a user key?23:04
cedkbechamel: what do you mean by double encryption?23:04
bechamelversion2beta: seriously I don't know23:04
version2betabechamel: I ask because I considered that ;-)23:05
version2betabechamel: The problem is that the master key is all you need to read everything then.23:05
bechamelwhat is revocation exactly ? disabling acces to a certain user ?23:05
cedkbechamel: yes, one employee leaves the company23:06
version2betabechamel: Yes. We need to be able to revoke a user's access to a repository, and add a new user after the fact.23:06
bechamelisn't revoking access simply disabling is account on the tryton server ?23:06
cedkversion2beta: by the way, why do you expect that the server will be compromised easier than the user hosts?23:06
version2betabechamel: Not in this case. A user might not leave, just no longer assigned to a certain case associated with a given repository.23:07
cedkbechamel: but the user will still have the key to decrypt everything23:07
version2betacedk: I don't expect it - certainly not. It's only that the document repository is the highest value target.23:07
cedkversion2beta: yes but I think the easiest way to attack will be from a user host instead of directly the server23:08
version2betacedk: I'm trying to make sure principle of least permission is filly implemented. No user should have access to any repository he or she is not assigned to. This should be implemented not through access controls, but through the actual encryption on the file, or at least access to the decryption key for that file.23:09
cedkespecially if the user host store the keys23:09
cedkversion2beta: i never read about such design23:10
version2betacedk: For better or worse, I'd put them on USB thumb drives.23:10
version2betacedk: It's been three years since I built the first system. Dunno if I could find the paper again, but I could try.23:10
bechamelso the double encryption is: 1) a (common) symetric key used by the client used to encrypt/decrypt attachemnt when saving/reading 2) pairs (a pair by user) of public/private keys: the public known server-side and the private used by the client to re-encrypt data a second time23:11
version2betabechamel: I think the double encryption works out to be like this: Each repository has a key pair used to encrypt documents in the repository. Each user with access to the repository has a copy of the private key for that repository, but it's encrypted with the user's own public key.23:15
bechamelbut all this complication is not usefull of one of the client machine is compromised23:15
version2betabechamel: If the user's private key is compromised, then the attacker would have access to anything the user had access to.23:16
cedkbechamel: yes and it is more complicated to ensure many machines to not be compromised than just one23:16
bechamelversion2beta: is "repository" a trytond server ?23:16
version2betabechamel: Sorry, I'm using repository to refer to a related collection of documents. In this case, a collection of documents supporting a mortgage application - the signed application itself, bank statements, pay check stubs, credit reports, etc.23:17
version2betabechamel: So each application has a repository of documents.23:17
cedkversion2beta: and how do you shared the key with users? You need to get them unencrypted somewhere?23:17
version2betabechamel: In a medical scenario, a repository could be patient records, xrays, mris, etc.23:18
bechamelversion2beta: I see23:18
version2betacedk: The user's private key is in his or her possession and needs to be provided through the client. Or, the client needs to support a decrypt method.23:19
cedkversion2beta: but how do you give him?23:19
version2betacedk: I secure it with a passphrase and copy it onto a thumb drive. The user plugs in the thumb drive when logging into Tryton.23:19
cedkversion2beta: you create a new repository and a new pair of key, so you must give it to the users who need access to this repository23:20
version2betacedk: The user model has the user's public key, so a Tryton module can encrypt any data so that only the user can use it. The repository's private key would be encrypted with the user's public key and saved for when they need it.23:21
version2betacedk: I should add "At least that's the best I've come up with, but it starts to feel really complicated and hard to follow..."23:23
cedkversion2beta: I understand the design but I think it is a complicate design that doesn't bring so much more security to the data23:25
cedkversion2beta: because all of this design is to try to prevent an attacker that will win access to the server to stole the data23:25
cedkversion2beta: so the design should be prevent this but it doesn't completly because the attacker can get the private key used to encrypt each repo when they are accessed23:27
cedkand the other solution is to share with all the users the key and the server doesn't know it23:28
version2betacedk: I agree it's a complicated design, especially when you look at assigning new users to a repository. But in terms of security, I think it covers everything but memory, right? Isn't that the only place an attacker, even with root access, can get the data required to decrypt anything?23:28
cedkso it is ok for a compromised server but the probability of a server being compromised seems less than for a user host23:28
version2betacedk: If you share the key with all the users, than any compromised user host can open all repositories.23:30
version2betacedk: Perhaps I'm missing a more important question here. I presume that one cannot much control the user. I can do two-factor authentication (I like the Yubico module, or we can use challenge-response with GPG). But if the user shares both key and password (or if an attacker obtains the information in any other way) all I can ever do is limit exposure.23:32
cedkversion2beta: I don't know if it is only memory but it is at least that so the security of a system is equal to his less secure point23:32
version2betacedk: least secure point times the value of the data accessible from that point. A janitor's key card might be easier to get than the IT director, but it won't do you as much good ;-)23:33
version2betacedk and bechamal, thank you both very much. I'll keep working on this. cedk: Thank you again for making the GPG connection - that library might make this easier.23:42
cedkversion2beta: I will continue to think about it23:48
version2betacedk: Thank you. I don't suppose you can point me off the top of your head at a good starting point for file attachment code in Tryton? I have no idea how it's organized, and should work around that rather than create anything new.23:50
bechamelcrypto stuff is always subtle :)23:50
cedkversion2beta: have a look at http://hg.tryton.org/trytond/file/e5f691f2222e/trytond/ir/attachment.py#l9523:56
version2betacedk: Thank you, that's perfect.23:57

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!