is there a secure store associated with user?

Tue Mar 8 17:30:22 UTC 2016

> On Mar 8, 2016, at 4:15 AM, Polytropon <freebsd at edvax.de> wrote:
> 
> 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.
> 
> 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.
> 
> 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?
> 
> 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. ;-)
> 
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’s 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.

> 
> 
>> Thus, Windows OS has to store a
>> form of user's password somewhere...
> 
> 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.
> 
> 
> 
>> 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.
> 
> 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).
> 
> I have something in mind which might not be a solution for you, but
> could help develop further ideas:
> 
> 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"…

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’t 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.

> 
>> 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.
> 
> That would be possible, but again involves the knowledge of the
> password (plain?) to possibly untrusted instances.
> 
> 
> 
>> 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.
> 
> 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.
> 
> 
> 
>> 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.
> 
> 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.
> 
> 
> 
>> Does it make any sense?  Is it too much protection for the payoff?
> 
> 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...
> 
> 
> 
>> Does something like this exist today?
> 
> Not that I'm aware of, but still possible.
> 
> 
> 
> 
> -- 
> Polytropon
> Magdeburg, Germany
> Happy FreeBSD user since 4.0
> Andra moi ennepe, Mousa, ...
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org”

The Lost Admin
thelostadmin at gmail.com