| chat.freenode.net #tryton log beginning Fri Aug 12 00:00:03 CEST 2011 | ||
| 2011-08-12 02:43 -!- dfamorato_(~dfamorato@2001:470:5:71c:3c0d:20fe:9c5d:190f) has joined #tryton | ||
| 2011-08-12 03:42 -!- dfamorato(~dfamorato@2001:470:5:71c:3c0d:20fe:9c5d:190f) has joined #tryton | ||
| 2011-08-12 04:25 -!- zxq9(~zxq9@FL1-119-244-163-75.okn.mesh.ad.jp) has joined #tryton | ||
| 2011-08-12 05:02 -!- yangoon1(~mathiasb@p54B4E5A9.dip.t-dialin.net) has joined #tryton | ||
| 2011-08-12 05:20 -!- ikks_(~ikks@190.27.144.25) has joined #tryton | ||
| 2011-08-12 08:11 -!- lem0na(~lem0na@95.87.233.210) has joined #tryton | ||
| 2011-08-12 08:29 -!- mr_amit(~amit@59.164.85.0) has joined #tryton | ||
| 2011-08-12 08:36 -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton | ||
| 2011-08-12 08:41 -!- okko1(~okko@62.58.29.41) has joined #tryton | ||
| 2011-08-12 09:20 -!- nicoe(~nicoe@ced.homedns.org) has joined #tryton | ||
| 2011-08-12 09:24 -!- pjstevns(~pjstevns@a83-163-46-103.adsl.xs4all.nl) has joined #tryton | ||
| 2011-08-12 09:53 -!- bechamel(~user@cismwks02-virtual1.cism.ucl.ac.be) has joined #tryton | ||
| 2011-08-12 09:53 -!- okko1(~okko@62.58.29.41) has joined #tryton | ||
| 2011-08-12 10:18 -!- elbenfreund(~elbenfreu@p54B94397.dip.t-dialin.net) has joined #tryton | ||
| 2011-08-12 11:37 -!- ccomb(~ccomb@did75-17-88-165-131-42.fbx.proxad.net) has joined #tryton | ||
| 2011-08-12 12:53 -!- ikks_(~ikks@190.27.84.116) has joined #tryton | ||
| 2011-08-12 13:10 -!- cheche(cheche@46.25.80.67) has joined #tryton | ||
| 2011-08-12 15:04 -!- alimon(alimon@187.156.80.54) has joined #tryton | ||
| 2011-08-12 15:31 -!- dfamorato(~dfamorato@173-9-190-185-miami.txt.hfc.comcastbusiness.net) has joined #tryton | ||
| 2011-08-12 16:34 -!- zodman(~zodman@foresight/developer/zodman) has joined #tryton | ||
| 2011-08-12 17:02 -!- pjstevns(~pjstevns@a83-163-46-103.adsl.xs4all.nl) has left #tryton | ||
| 2011-08-12 17:59 -!- sharkcz(~sharkcz@2001:15c0:6747:160::7) has joined #tryton | ||
| 2011-08-12 20:33 -!- elbenfreund(~elbenfreu@p54B94397.dip.t-dialin.net) has joined #tryton | ||
| 2011-08-12 21:06 -!- ccomb(~ccomb@vau75-2-81-57-244-84.fbx.proxad.net) has joined #tryton | ||
| 2011-08-12 21:18 -!- reichlich(~reichlich@p578E8BB2.dip.t-dialin.net) has joined #tryton | ||
| 2011-08-12 21:34 -!- Ildin(~chatzilla@184-76-111-12.war.clearwire-wmx.net) has left #tryton | ||
| 2011-08-12 21:34 -!- Ildin(~chatzilla@184-76-111-12.war.clearwire-wmx.net) has joined #tryton | ||
| 2011-08-12 21:46 <Ildin> Has the port for demo2.1.tryton.org been changed to 8000? or should I still be using 8070? | ||
| 2011-08-12 21:48 -!- plantian(~ian@c-67-169-72-36.hsd1.ca.comcast.net) has joined #tryton | ||
| 2011-08-12 21:54 -!- version2beta(~rob@24.106.58.138) has joined #tryton | ||
| 2011-08-12 21:56 <cedk> Ildin: there is no demo2.1 server | ||
| 2011-08-12 21:56 <Ildin> Oh. | ||
| 2011-08-12 21:57 <Ildin> I had just run hg nclone http://hg.tryton.org/tryton/ and the default settings pointed to demo2.1.tryton.org:8000. | ||
| 2011-08-12 21:57 <Ildin> My bad... | ||
| 2011-08-12 21:58 <Ildin> -->(The default settings for the Tryton client.) | ||
| 2011-08-12 22:06 <cedk> Ildin: it is the development version | ||
| 2011-08-12 22:09 -!- bechamel(~user@host-85-201-144-79.brutele.be) has joined #tryton | ||
| 2011-08-12 22:17 <version2beta> Is anyone here familiar with Yubico yubikeys and maybe Openlab's Yubico module? | ||
| 2011-08-12 22:17 <version2beta> Looking to discuss some security/encryption ideas... | ||
| 2011-08-12 22:18 <cedk> version2beta: I had taken a look at it | ||
| 2011-08-12 22:18 <cedk> version2beta: I know the big picture of the design | ||
| 2011-08-12 22:20 <version2beta> cedk: 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. | ||
| 2011-08-12 22:21 <version2beta> cedk: 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. | ||
| 2011-08-12 22:21 <cedk> version2beta: I don't think | ||
| 2011-08-12 22:22 <version2beta> cedk: 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. | ||
| 2011-08-12 22:23 <cedk> version2beta: for what I read, Yubikey provides only authentication mechanism | ||
| 2011-08-12 22:24 <version2beta> cedk: 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? | ||
| 2011-08-12 22:24 <cedk> version2beta: of course it can be used to give access to the documents but the documents will be delivery unencrypted | ||
| 2011-08-12 22:26 <cedk> version2beta: will you autorise user to get unencrypted documents? | ||
| 2011-08-12 22:27 <version2beta> cedk: 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). | ||
| 2011-08-12 22:27 <version2beta> cedk: Sorry, "users with access" | ||
| 2011-08-12 22:27 <cedk> version2beta: so a simple authentication on the HTTPS will do the job | ||
| 2011-08-12 22:28 <cedk> version2beta: with Yubikey if you want | ||
| 2011-08-12 22:29 <version2beta> cedk: 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. | ||
| 2011-08-12 22:31 <version2beta> cedk: 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. | ||
| 2011-08-12 22:32 -!- Ildin(~chatzilla@184-76-111-12.war.clearwire-wmx.net) has joined #tryton | ||
| 2011-08-12 22:32 <cedk> version2beta: this sounds paranoic :-) | ||
| 2011-08-12 22:32 <version2beta> cedk: Oh most definitely. ;-) | ||
| 2011-08-12 22:33 <cedk> version2beta: if you store the data encrypted on the server, you need to be able to get the key to decrypt in some way | ||
| 2011-08-12 22:33 <cedk> version2beta: so the server could ask to an other host... | ||
| 2011-08-12 22:34 <cedk> version2beta: wait I have perhaps an idea | ||
| 2011-08-12 22:34 <version2beta> cedk: 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. | ||
| 2011-08-12 22:34 <cedk> version2beta: you could store the same private key many times but crypted with the password of the user | ||
| 2011-08-12 22:35 <cedk> version2beta: so when the user query for the document, he must give also his password and the server can decrypt the document on the fly | ||
| 2011-08-12 22:36 <version2beta> cedk: 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. | ||
| 2011-08-12 22:37 <cedk> version2beta: but I don't think all this prevent the data to be stolen if the server is compromised when running | ||
| 2011-08-12 22:37 <version2beta> cedk: Because the assailant can read the private keys from memory? | ||
| 2011-08-12 22:38 <cedk> version2beta: yes but also he can make man-in-the-middle | ||
| 2011-08-12 22:38 <cedk> version2beta: or retrieve the document on the network interface when their are send | ||
| 2011-08-12 22:38 <version2beta> cedk: In which case, the user needs to also have a key pair, like an X509 certificate | ||
| 2011-08-12 22:39 <version2beta> cedk: The document on the wire is encrypted over https... | ||
| 2011-08-12 22:39 <cedk> version2beta: but the HTTP server have the document unencrypted | ||
| 2011-08-12 22:39 <cedk> version2beta: also the encryption keys of the https is know by the http server | ||
| 2011-08-12 22:40 <version2beta> cedk: Yes, that is true. So an assailant on the machine can have access to each document as it is retrieved. | ||
| 2011-08-12 22:41 <version2beta> cedk: How difficult would it be to put openssl decryption into the Tryton client? | ||
| 2011-08-12 22:41 <cedk> version2beta: I'm not sure it is possible to design a service that will be protected against a assailant that get root access | ||
| 2011-08-12 22:42 <cedk> version2beta: the Tryton client already uses ssl | ||
| 2011-08-12 22:42 <cedk> version2beta: and there is fingerprint verfication and you can add ca check | ||
| 2011-08-12 22:43 <version2beta> cedk: 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. | ||
| 2011-08-12 22:43 <version2beta> cedk: X509 or similar I guess. I'm not sure that the CA is ideal. | ||
| 2011-08-12 22:44 <cedk> version2beta: you mean that you want the client authenticate to the server with a certificate? | ||
| 2011-08-12 22:45 <version2beta> cedk: 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. | ||
| 2011-08-12 22:46 <cedk> version2beta: ok like gpg | ||
| 2011-08-12 22:46 <version2beta> cedk: Perfect. Yes. | ||
| 2011-08-12 22:46 <cedk> version2beta: don't know if there is python lib to manipulate gpg | ||
| 2011-08-12 22:47 <version2beta> cedk: http://packages.python.org/python-gnupg/ | ||
| 2011-08-12 22:47 <cedk> version2beta: yep found it | ||
| 2011-08-12 22:48 <cedk> version2beta: it is only document or you want to encrypt every data? | ||
| 2011-08-12 22:49 <version2beta> cedk: For this project it is only documents. | ||
| 2011-08-12 22:49 <cedk> version2beta: the attachment? | ||
| 2011-08-12 22:50 <version2beta> cedk: Not sure I understand, but yes, I think so. I'd like to pass encrypted files from a URI to the client. | ||
| 2011-08-12 22:50 <version2beta> cedk: But they could be stored as Tryton attachments. | ||
| 2011-08-12 22:51 <cedk> version2beta: ha the data are not stored in Tryton database? | ||
| 2011-08-12 22:51 <version2beta> cedk: I think that might be a bad idea. These are 30 - 50 page scans, one or more per repository, 50 or more a day. | ||
| 2011-08-12 22:52 <cedk> version2beta: in Tryton attachment are stored in the filesystem with just a link from the database | ||
| 2011-08-12 22:53 <version2beta> cedk: 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.) | ||
| 2011-08-12 22:54 <cedk> version2beta: 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 it | ||
| 2011-08-12 22:54 <cedk> version2beta: and it should be possible to have also the WebDAV services working like that | ||
| 2011-08-12 22:55 <version2beta> cedk: 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... | ||
| 2011-08-12 22:56 <version2beta> cedk: That was cryptic. Sorry. I'll try to explain... | ||
| 2011-08-12 22:56 <cedk> version2beta: you could store it in a fs that is encrypted | ||
| 2011-08-12 22:57 <cedk> version2beta: like that if the server hd is stolen, data can not be read | ||
| 2011-08-12 22:57 <version2beta> cedk: 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? | ||
| 2011-08-12 22:59 <version2beta> cedk: 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. | ||
| 2011-08-12 22:59 <cedk> version2beta: yes but I don't see it as an security improvement for the server-side | ||
| 2011-08-12 23:00 <cedk> version2beta: but I'm not really a security expert :-) | ||
| 2011-08-12 23:00 <version2beta> cedk: 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. | ||
| 2011-08-12 23:01 <version2beta> cedk: Sorry, I hope I'm not bugging you too much. It's an interesting problem for me :-) | ||
| 2011-08-12 23:01 <cedk> version2beta: but even with excryption document could be retreived | ||
| 2011-08-12 23:02 <version2beta> cedk: With file based encryption, even 1024-bit RSA, it'll take a pretty sophisticated attacker to get anything useful. | ||
| 2011-08-12 23:02 <cedk> version2beta: 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 decrypt | ||
| 2011-08-12 23:02 <bechamel> what 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 network | ||
| 2011-08-12 23:02 -!- alimon(alimon@187.156.94.122) has joined #tryton | ||
| 2011-08-12 23:03 <bechamel> and the document are never decrypted server-side | ||
| 2011-08-12 23:03 <cedk> bechamel: I guess the issue is to revoke access to someone | ||
| 2011-08-12 23:03 <bechamel> and the server doesn't know the keys at all | ||
| 2011-08-12 23:03 <version2beta> cedk: The key is only useful for documents in that repository. In our case, three or four documents for one loan application. | ||
| 2011-08-12 23:03 <bechamel> cedk: double encryption ! :) | ||
| 2011-08-12 23:04 <version2beta> bechamel: So there's a master key and a user key? | ||
| 2011-08-12 23:04 <cedk> bechamel: what do you mean by double encryption? | ||
| 2011-08-12 23:04 <bechamel> version2beta: seriously I don't know | ||
| 2011-08-12 23:05 <version2beta> bechamel: I ask because I considered that ;-) | ||
| 2011-08-12 23:05 <version2beta> bechamel: The problem is that the master key is all you need to read everything then. | ||
| 2011-08-12 23:05 <bechamel> what is revocation exactly ? disabling acces to a certain user ? | ||
| 2011-08-12 23:06 <cedk> bechamel: yes, one employee leaves the company | ||
| 2011-08-12 23:06 <version2beta> bechamel: Yes. We need to be able to revoke a user's access to a repository, and add a new user after the fact. | ||
| 2011-08-12 23:06 <bechamel> isn't revoking access simply disabling is account on the tryton server ? | ||
| 2011-08-12 23:06 <cedk> version2beta: by the way, why do you expect that the server will be compromised easier than the user hosts? | ||
| 2011-08-12 23:07 <version2beta> bechamel: Not in this case. A user might not leave, just no longer assigned to a certain case associated with a given repository. | ||
| 2011-08-12 23:07 <cedk> bechamel: but the user will still have the key to decrypt everything | ||
| 2011-08-12 23:07 <version2beta> cedk: I don't expect it - certainly not. It's only that the document repository is the highest value target. | ||
| 2011-08-12 23:08 <cedk> version2beta: yes but I think the easiest way to attack will be from a user host instead of directly the server | ||
| 2011-08-12 23:09 <version2beta> cedk: 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. | ||
| 2011-08-12 23:09 <cedk> especially if the user host store the keys | ||
| 2011-08-12 23:10 <cedk> version2beta: i never read about such design | ||
| 2011-08-12 23:10 <version2beta> cedk: For better or worse, I'd put them on USB thumb drives. | ||
| 2011-08-12 23:10 <version2beta> cedk: It's been three years since I built the first system. Dunno if I could find the paper again, but I could try. | ||
| 2011-08-12 23:11 <bechamel> so 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 time | ||
| 2011-08-12 23:15 <version2beta> bechamel: 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. | ||
| 2011-08-12 23:15 <bechamel> but all this complication is not usefull of one of the client machine is compromised | ||
| 2011-08-12 23:16 <version2beta> bechamel: If the user's private key is compromised, then the attacker would have access to anything the user had access to. | ||
| 2011-08-12 23:16 <cedk> bechamel: yes and it is more complicated to ensure many machines to not be compromised than just one | ||
| 2011-08-12 23:16 <bechamel> version2beta: is "repository" a trytond server ? | ||
| 2011-08-12 23:17 <version2beta> bechamel: 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. | ||
| 2011-08-12 23:17 <version2beta> bechamel: So each application has a repository of documents. | ||
| 2011-08-12 23:17 <cedk> version2beta: and how do you shared the key with users? You need to get them unencrypted somewhere? | ||
| 2011-08-12 23:18 <version2beta> bechamel: In a medical scenario, a repository could be patient records, xrays, mris, etc. | ||
| 2011-08-12 23:18 <bechamel> version2beta: I see | ||
| 2011-08-12 23:19 <version2beta> cedk: 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. | ||
| 2011-08-12 23:19 <cedk> version2beta: but how do you give him? | ||
| 2011-08-12 23:19 <version2beta> cedk: I secure it with a passphrase and copy it onto a thumb drive. The user plugs in the thumb drive when logging into Tryton. | ||
| 2011-08-12 23:20 <cedk> version2beta: you create a new repository and a new pair of key, so you must give it to the users who need access to this repository | ||
| 2011-08-12 23:21 <version2beta> cedk: 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. | ||
| 2011-08-12 23:23 <version2beta> cedk: 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..." | ||
| 2011-08-12 23:25 <cedk> version2beta: I understand the design but I think it is a complicate design that doesn't bring so much more security to the data | ||
| 2011-08-12 23:25 <cedk> version2beta: because all of this design is to try to prevent an attacker that will win access to the server to stole the data | ||
| 2011-08-12 23:27 <cedk> version2beta: 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 accessed | ||
| 2011-08-12 23:28 <cedk> and the other solution is to share with all the users the key and the server doesn't know it | ||
| 2011-08-12 23:28 <version2beta> cedk: 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? | ||
| 2011-08-12 23:28 <cedk> so it is ok for a compromised server but the probability of a server being compromised seems less than for a user host | ||
| 2011-08-12 23:30 <version2beta> cedk: If you share the key with all the users, than any compromised user host can open all repositories. | ||
| 2011-08-12 23:32 <version2beta> cedk: 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. | ||
| 2011-08-12 23:32 <cedk> version2beta: 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 point | ||
| 2011-08-12 23:33 <version2beta> cedk: 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 ;-) | ||
| 2011-08-12 23:42 <version2beta> cedk 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. | ||
| 2011-08-12 23:48 <cedk> version2beta: I will continue to think about it | ||
| 2011-08-12 23:50 <version2beta> cedk: 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. | ||
| 2011-08-12 23:50 <bechamel> crypto stuff is always subtle :) | ||
| 2011-08-12 23:56 <cedk> version2beta: have a look at http://hg.tryton.org/trytond/file/e5f691f2222e/trytond/ir/attachment.py#l95 | ||
| 2011-08-12 23:57 <version2beta> cedk: Thank you, that's perfect. |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!