hiding encryption keys

On 15 Aug 2005 05:53:52 +0200, Volker Birk wrote:

> OK. I will not talk about Win9x and security. This is an Oxymoron.

so is your mother and not fucking the entire russki army.

Volker Birk wrote:
> TC <aatcbbtccctc@yahoo.com> wrote:
> > He has not said what OS he is on
>
> He told us, there is a "Registry". How many OSes are there, which
> have one?

Hi,

Thanks for all the responses. The OS is Windows 2k3 and the keys are
client keys for an app that are encrypted as well. In order to decrypt
the client keys from the buried location, an unmanaged binary DLL
library will perform the decryption of the keys and utilize those keys
in a string to access a backend DB where data lives in an encrypted
form. Hope that helps clarify to some degree. Does that change
people's comfort level or does the whole setup still sound like a
horrid idea?

Phillip.

>
> > how it has been set up
>
> That does not matter. He told us, that he want's to use obscurity to
> store keys, not encryption.
>
> Yours,
> VB.
> --
> "Almighty Father, who wilt hear the prayer of those that love Thee, we pray
> Thee to be with those who brave heights of Thy heaven and who carry the
> battle to our enemies. Guard and protect them, we pray Thee, as they fly
> the appointed rounds." - Chaplain William Downey, prayer for the Enola Gay.

Thanks much. It is Windows 2k3. We would restrict access to the keys
to a service account and the keys are encrypted. More info on this in
an above reply. Thanks again.

Phillip

Correct, the problem is not an SSL server, which the site would be.
The issue is storing confidential data on a backend system that a
front-end web app would need to utilize in some operations.

Phillip

phillipkim1@yahoo.com writes:
> Correct, the problem is not an SSL server, which the site would be.
> The issue is storing confidential data on a backend system that a
> front-end web app would need to utilize in some operations.

This is very confusing. Do you mean you're trying to store something
like a database password in a server-side web app? When you talk
about putting keys in the registry, that sounds like you want to put
keys in a client-side desktop machine, not a backend system.

Can you say in more detail what you're doing?

Sorry for the confusion. The keys, which are encrypted, live on both a
backend DB and front-end application server.

There is data living in the backend DB which is encrypted with these
keys. When the front-end application needs to access this information,
a binary library DLL will decrypt the encryption keys from their
storage location and use those keys to send a query to access the
encrypted data on the backend DB.

No one (in theory) outside of inhouse staff would have local access to
the front-end app server and the only mechanism to decrypt the keys
living on the front-end server would be the binary DLL.

Let me know if you have more questions or need more clarification...

Thanks,

Phillip

Paul Rubin wrote:
> phillipkim1@yahoo.com writes:
> > Correct, the problem is not an SSL server, which the site would be.
> > The issue is storing confidential data on a backend system that a
> > front-end web app would need to utilize in some operations.
>
> This is very confusing. Do you mean you're trying to store something
> like a database password in a server-side web app? When you talk
> about putting keys in the registry, that sounds like you want to put
> keys in a client-side desktop machine, not a backend system.
>
> Can you say in more detail what you're doing?

Sorry for the confusion. The keys, which are encrypted, live on both a
backend DB and front-end application server.

There is data living in the backend DB which is encrypted with these
keys. When the front-end application needs to access this information,
a binary library DLL will decrypt the encryption keys from their
storage location and use those keys to send a query to access the
encrypted data on the backend DB.

No one (in theory) outside of inhouse staff would have local access to
the front-end app server and the only mechanism to decrypt the keys
living on the front-end server would be the binary DLL.

Let me know if you have more questions or need more clarification...

Thanks,

Phillip

Paul Rubin wrote:
> phillipkim1@yahoo.com writes:
> > Correct, the problem is not an SSL server, which the site would be.
> > The issue is storing confidential data on a backend system that a
> > front-end web app would need to utilize in some operations.
>
> This is very confusing. Do you mean you're trying to store something
> like a database password in a server-side web app? When you talk
> about putting keys in the registry, that sounds like you want to put
> keys in a client-side desktop machine, not a backend system.
>
> Can you say in more detail what you're doing?

phillipkim1@yahoo.com writes:


>Volker Birk wrote:
>> TC <aatcbbtccctc@yahoo.com> wrote:
>> > He has not said what OS he is on
>>
>> He told us, there is a "Registry". How many OSes are there, which
>> have one?

>Hi,

>Thanks for all the responses. The OS is Windows 2k3 and the keys are
>client keys for an app that are encrypted as well. In order to decrypt
>the client keys from the buried location, an unmanaged binary DLL
>library will perform the decryption of the keys and utilize those keys
>in a string to access a backend DB where data lives in an encrypted
>form. Hope that helps clarify to some degree. Does that change
>people's comfort level or does the whole setup still sound like a
>horrid idea?

Depends on who you are protecting against. Against the common kiddie,
probably fine, against a determined attacker no. (the encryption guards
against direct theft, but not using the dll to do the decryption.)
Better would probably be to put the system on a computer not hooked up to
the net except directly to one of the computers. It has only one port open
to which database queries are sent and which responds. And if it gets too
many queries in a certain time, it refuses to respond.

>Phillip.

>>
>> > how it has been set up
>>
>> That does not matter. He told us, that he want's to use obscurity to
>> store keys, not encryption.
>>
>> Yours,
>> VB.
>> --
>> "Almighty Father, who wilt hear the prayer of those that love Thee, we pray
>> Thee to be with those who brave heights of Thy heaven and who carry the
>> battle to our enemies. Guard and protect them, we pray Thee, as they fly
>> the appointed rounds." - Chaplain William Downey, prayer for the Enola Gay.

Um, not sure who that was, Volker, but it was not me.

TC

aatcbbtccctc@yahoo.com wrote:
> Um, not sure who that was, Volker, but it was not me.

No problem.

This is usenet. Anybody can write here, also the people, who are up
the pole.

I don't think, you have this problem ;-) So this posting was not by you.

Yours,
VB.
--
"Almighty Father, who wilt hear the prayer of those that love Thee, we pray
Thee to be with those who brave heights of Thy heaven and who carry the
battle to our enemies. Guard and protect them, we pray Thee, as they fly
the appointed rounds." - Chaplain William Downey, prayer for the Enola Gay.

On 16 Aug 2005 06:13:45 +0200, Volker Birk wrote:

> aatcbbtccctc@yahoo.com wrote:
>> Um, not sure who that was, Volker, but it was not me.
>
> No problem.
>
> This is usenet. Anybody can write here, also the people, who are up
> the pole.
>
> I don't think, you have this problem ;-) So this posting was not by you.
>
> Yours,
> VB.

im surprised that you dont know a dick when you slurp one, birkdick

Phillip wrote:
> Correct, the problem is not an SSL server, which the site would be.
> The issue is storing confidential data on a backend system that a
> front-end web app would need to utilize in some operations.

More information is needed, especially about the system configuration,
location and value of secrets, etc.

Often root keys / passwords are protected by file system permissions (ie
only root or file owner can view...for example, ssh keys). If you are
willing to make the necessary assumptions, then that may be sufficient.
Consider that to defeat this, you could either steal the root or owner's
password, or gain physical access to the filesystem (in which case, for
example, you can install the hard drive in another system or boot from a
linux live cd, and then examine and potentially change the drive contents).
Or you could exploit an unpatched vulnerability to gain root access...etc.
So you must patch diligently, prevent physical access, and have a strong
root password which you protect well and change frequently. If you do these
things, then file system permissions may be sufficient for protecting the
secret. Still it is advisable to protect any on-disk secrets with an
off-disk secret (pass phrase, removable hardware key, etc). Even then, a
user who can become root or can gain physical access will be able to steal
your secret.

Alan

<phillipkim1@yahoo.com> wrote in message
news:1124129492.505567.148660@o13g2000cwo.googlegr oups.com...
> Correct, the problem is not an SSL server, which the site would be.
> The issue is storing confidential data on a backend system that a
> front-end web app would need to utilize in some operations.

The correct solution to that is to pick something from
http://www.ncipher.com/
http://www.eracom.com.au/
http://www.safenet-inc.com/
or similar that meets your needs. These are all hardware and prevent the
extraction of the key under the vast majority of usage scenarios, some also
provide significant amounts of SSL offload.
Joe