Date: Tue, 8 Mar 2016 12:30:17 -0500 From: The Lost Admin <thelostadmin@gmail.com> To: Polytropon <freebsd@edvax.de> Cc: Sergei G <sergeig.public@gmail.com>, "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Subject: Re: is there a secure store associated with user? Message-ID: <C00CF639-6B16-49F1-9070-57298D183248@gmail.com> In-Reply-To: <20160308101535.d191de76.freebsd@edvax.de> References: <CAFLLzCNNKZiXVJRYLD=URwhFRfkKo=NhR78cZBH8tOKZPow=kQ@mail.gmail.com> <20160302215421.53c9a7be.freebsd@edvax.de> <CAFLLzCN%2BYhgCWTrafbPgG5HFY744tqcJeQgORnC6Ui83BDN9uA@mail.gmail.com> <20160308101535.d191de76.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Mar 8, 2016, at 4:15 AM, Polytropon <freebsd@edvax.de> wrote: >=20 > First of all, thanks for describing your requirements more precisely. > As it seems, using standard permissions or ACLs is not going to work > for you. But allow me to throw in some further thoughts. >=20 > On Tue, 8 Mar 2016 00:23:21 -0800, Sergei G wrote: >> MS DPAPI is secure, because it relies on user's password to encrypt = user's >> data store. However, when windows services are involved, windows = service >> control manager (SCM) needs to store user's password, so it can = unlock >> DPAPI store when it starts the service. >=20 > This somehow invalidates your first sentence. Is the password known > to the service in plain text? Is it _stored_ in plain text? Or does > the service store something like a hash or somehow encrypted password, > and just checks "crypted vs. crypted" instead of "plain vs. plain" > after decrypt? >=20 > I won't go into detail about my feelings considering the idea that > a closed source product licensed from an NSA strategic partner can > be regarded "secure" - forgive my tinfoilhatness. ;-) >=20 MS DPAPI uses a variation on the PBKDF2 key generation algorithm = (https://msdn.microsoft.com/en-CA/library/ms995355.aspx) to generate a = key-encrypting-key for the user. The PBKDF2 uses the end-user=E2=80=99s = plain text password as a starting point along with a magic number from = the server itself. This key-encrypting-key is used to encrypt the data = encrypting key for storage on the server. When you use MS DPAPI in conjunction with a service that starts = automatically, the Data Encrypting Key is encrypted using a key unique = to the server that the service runs on. The exact nature and protection = around that key-encrypting-key depends on the hardware capabilities of = the server. It will use the Intel TPM, if available but can be = configured to not use. MS Windows (the Operating system) is built to protect the KEK from all = users, including administrators. It might be possible for a skilled = malicious hacker to bypass the OS protections and read the key directly = from RAM but if the Intel TPM is used for the system master-key storage, = it should not be possible to extract the data encrypting key from a disk = image or stolen hard disk. There are actually more layers of keys than I am describing above but it = gives you an idea. >=20 >=20 >> Thus, Windows OS has to store a >> form of user's password somewhere... >=20 > Exactly - this is one entity knowing the "keys to the kingdom" you > cannot trust. There are good and bad ways how to deal with passwords. > The best way is to not store them at all, the worst way is to store > them in plaintext. >=20 >=20 >=20 >> Our goal is to apply defense in depth and in this case it is a = protection >> of CONTENT of a file in case it was downloaded by an attacker. = Standard >> ACL solution does not work, because www user by definition has access = to a >> file's content to be able to work with (load it into application = memory). >> The file is not meant to be served, but it may be serviced due to a >> vulnerability or misconfiguration. That's the scenario that we are >> defending against. >=20 > Now I understand. You'd still encounter the problem that an attacker > will retrieve the data at a stage where it is _not_ encrypted, and > there definitely is such a stage, i.e., when the data is going to > be used (read or written). >=20 > I have something in mind which might not be a solution for you, but > could help develop further ideas: >=20 > Imagine the data is stored in a disk image. This image is encrypted, > so if the attacker gets the image, it's of no value. This image is > being mounted (read only or read/write, as needed) and decrypted > "through" a trusted "access layer". Modifications can only happen > at that time. After use, the image is unmounted and therefore > encrypted again. I'm obviously talking about a file system image > plus some kind of PGP layer. I think it is possible to implement > this with "SSH + NFS", or somehow "mount + PGP"=E2=80=A6 You might want to have a look at fuse and encfs. The key management for = encfs sucks but fuse has the advantage of working in user space. So, = only the user that actually mounted the filesystem with fuse can see the = mount point (by default). I found a fuse filesystem that uses gpg for file management but it was = written entirely in python which seams to defeat the purpose to me for = many reason. I would say you need something that supports a key server to properly = protect the encryption keys. I have tested the scenario where I use encfs to encrypt/decrypt files on = one server with the files themselves stored on an NFS share mounted from = a different server. I.e. Server A runs encfs and acts as a NFS client. = Server B is an NFS server and does not have the encryption keys. I = wouldn=E2=80=99t call this true defence in depth since an attacker can = trivially gain the encryption key if they get root (or the right user) = privileges on server A). To make the above more secure, a key server and modifications to key = management for encfs would be needed. >=20 >> One solution could be the deployment of a "security service" = providing data >> over a Unix file socket. The "security service" simply returns = password to >> the application and application decrypts sensitive data on the fly or = uses >> this password to establish DB connection. A direct download of file's >> content would not result in sensitive data exposure. >=20 > That would be possible, but again involves the knowledge of the > password (plain?) to possibly untrusted instances. >=20 >=20 >=20 >> The compromise is only possible if attacker gains ability to execute >> arbitrary code as www user and instructs system to connect to = "security >> service". The same is true to DPAPI protection. If attacker can = execute >> arbitrary code as a service user, then he or she can return = originally >> protected data in plain text form. >=20 > Being able to execute untrusted code basically is GAME OVER, > especially when running with non-trivial system privilege. > It would require that the associated user (corresponding to > the service) is only allowed to execute _one_ verified binary > image. >=20 >=20 >=20 >> In some way this is similar to WSC-DPAPI at the conceptual level. = WSC >> knows the user's password, unlocks user's store and starts = application with >> user's context. This "security service" plays a similar 3rd party = role of >> knowing the password and returning it. Unfortunately, some form of >> application ACL is necessary in this case. >=20 > Again, too much "know the password" is involved here. But maybe > this is inevitable for the setting you're describing. In that > case, it would sound possible to implement something like this > in Linux or UNIX. I don't know of a particular program which > does this, but I'd say it's more or less trivial: When access > to a file is requested which is under "user password control", > the service decrypts the file (knowing the required password), > and upon close(), re-encrypts it again. >=20 >=20 >=20 >> Does it make any sense? Is it too much protection for the payoff? >=20 > It's an additional means of security, but no "one size cures > all" approach. Just given the password is "password", "12345", > or "correcthorsebatterystaple", a quick dictionary-based attack > on an extracted encrypted file will reveal the content - and > will confirm that this password is valid for _other_ files > associated with that user... >=20 >=20 >=20 >> Does something like this exist today? >=20 > Not that I'm aware of, but still possible. >=20 >=20 >=20 >=20 > --=20 > Polytropon > Magdeburg, Germany > Happy FreeBSD user since 4.0 > Andra moi ennepe, Mousa, ... > _______________________________________________ > freebsd-questions@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to = "freebsd-questions-unsubscribe@freebsd.org=E2=80=9D The Lost Admin thelostadmin@gmail.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C00CF639-6B16-49F1-9070-57298D183248>