[Authentication] Applications storing secrets in configuration

[Anders Rundgren]

On 2013-05-22 18:27, Stef Walter wrote:
> On 22.05.2013 18:06, Anders Rundgren wrote:
>> On 2013-05-22 17:49, Stef Walter wrote:
>>> On 18.05.2013 07:24, Anders Rundgren wrote:
>>>> On 2013-05-11 08:57, Stef Walter wrote:
>>>>> On 11.05.2013 08:18, Anders Rundgren wrote:
>>>>>> Having application-local secrets is fine but there are tons of applications
>>>>>> that rather needs ACL-protected secrets (keys).
>>>>>>
>>>>>> It would for example be awesome dropping the gazillion key-passwords
>>>>>> stored (usually in clear) in various config files when you for example
>>>>>> deploy TLS-using application servers like JBoss.
>>>>>
>>>>> This is *exactly* what this proposal solves. It allows application
>>>>> servers (and desktop applications) and such to encrypt such passwords in
>>>>> their configuration in a standard manner rather than placing them there
>>>>> in the clear.
>>>>
>>>> This is not what I'm requesting.  Statically configured passwords in config
>>>> files (encrypted or not), does not add anything to the security of the system,
>>>> they are only a nuisance.  Such keys should IMO be managed by the OS including
>>>> the execution of private/secret-key operations.
>>>
>>> Right, that does make sense in many cases, and where that's the case, we
>>> should indeed be pushing down the private/secret-key operations to the OS level.
>>
>> Who in the Open Source community is actually working with that?
> 
> I've been doing some work on it with the p11-glue effort, with a focus
> on private-keys and certificates.
> 
> In addition there has been the Meego effort using libaccounts and the
> sso daemon. I believe Alberto Mardegan did that work.
> 
> There is also stuff gnome-online-accounts and ubuntu-online-accounts
> which perform authentication operations on behalf of applications.
> 
> It's pretty easy for us to sit around and complain that this is far from
> a comprehensive effort, but such is life. It's not an area that has been
> attracting much volunteer effort and progress has been slow.

I'm a bit worried about this.

> 
> If you can think of other concrete but discrete and small steps which
> you would like to contribute towards or try and coordinate in the Open
> Source community then I'd be happy to work with you on that.

I started in another end of this giant puzzle: Creating an architecture for
a secure keystore and compatible provisioning system.
http://openkeystore.googlecode.com/svn/trunk/resources/docs/sks-api-arch.pdf

This scheme does not build on PKCS #11 because PKCS #11 wasn't designed
for on-line provisioning of credentials.  Upgrading PKCS #11 to that
level is IMO unrealistic.  Fortunately provisioned credentials are
suitable for consumption by most crypto APIs including PKCS #11.

A somewhat troubling fact is that Open Source parties like Mozilla and
Redhat are uninterested in on-line provisioning; Mozilla still relies
on the 18-19 year old Netscape hack known as <keygen>!

So my plan is providing everything from browser-integration down to silicon
rather than hoping that a gazillion of disparate efforts eventually will lead
to something generally useful.

Currently a feature-complete PoC running at "app-level" in Android is available at:
https://code.google.com/p/openkeystore/downloads/detail?name=webpkisuite-4-android.apk
For CA support KeyGen2 is integrated in EJBCA: http://ejbca.org
A semi-public, very preliminary test-site is located at: https://mobilepki.org/scc

Cheers,
Anders


> 
>> Related:
>> http://goo.gl/DFLnS
> 
> This is very interesting. Thanks for sharing it. As the
> document/presentation notes there is a need for public standards
> surrounding these new concepts (such as setup vs. sign in).
> 
>>> But elsewhere plain ol' passwords are used by
>>> applications/infrastructure to access services such as email, websites,
>>> shared secrets in services, and so on. What this concept gives such
>>> applications is a way to store these appropriately.
>>
>> I think this should be addressed at the OS-level as well, like
>> it is in Android.   For a developer it is very convenient to
>> just declare a file as private.
> 
> As it is on Linux. The distinction is obviously that the file would be
> user-private and not application-private. This missing capability is
> being worked on in various communities by the efforts surrounding
> sandboxing on Linux.
> 
> If one is unable to access the storage other than through the OS then
> marking a file as private is all that is needed. For laptop hardware,
> additionally encrypting these private files (or parts) of them is
> desirable to prevent removal of the disk and bypassing access
> restrictions in that manner.
> 
> Providing the facility for applications to encrypt these parts of files
> allows the private files to contain secrets on laptops/desktops where
> such bypassing of the OS to access disk data is routine.
> 
> As such this is a secondary measure, and only relevant for certain devices.
> 
> Cheers,
> 
> Stef
> 
>