| Subject | Re: [IB-Architect] Fw: Mischievous SYSDBA |
|---|---|
| Author | Jan Mikkelsen |
| Post date | 2000-05-27T04:22:53Z |
Doug Chamberlin <dchamberlin@...> wrote:
you can validate them without any online dialogue.
An X.509 certificate consists of a bunch of certificate data and a
"signature". The signature is a hash of the certificate data computed using
an known and cryptograpically secure algorithm encrypted using the private
key of the signer. To verify the signature you decrypt the signature using
the public key of the signer (which must be known) and compare that with the
recomputed hash. If they match, the certificate is valid and has not been
tampered with.
Note the information required: The public key of the signer (typically a
Certification Authority or "CA") must be installed into the system using a
trusted mechanism. If the CA certificate is altered, the entire system can
be compromised.
I didn't really read the original requirement, but I recall it being
something along the lines of hiding a database schema. The basic principle
is this: If software in the user's environment can decrypt the schema for
use, and the user can examine state of the software while it is running, the
user can acquire the key and then acquire the information in the clear. As
Jim Starkey has pointed out, it might be obscure enough, but it isn't
security.
Controlling the environment through hardware can make things more secure: A
device with secure key storage with some cryptographic functions can help
ensure that the user can't observe the key. However, cost goes up,
usability goes down, and if you don't spend enough, performance goes down.
Jan Mikkelsen
>At 5/26/00 06:37 PM (Friday), Jan Mikkelsen wrote:at
>>Unless I've missed something fundamental, the executables are just files
>>the end user's site, and the whole point of the exercise has beendefeated.
>No. The whole point about a certificate signed by a well known CA is that
>Isn't the missing fundamental item that the digital certificates are
>validated by a third party at runtime? If you alter them or replace them
>with other certificates the third party certificate authority will not
>validate them.
you can validate them without any online dialogue.
An X.509 certificate consists of a bunch of certificate data and a
"signature". The signature is a hash of the certificate data computed using
an known and cryptograpically secure algorithm encrypted using the private
key of the signer. To verify the signature you decrypt the signature using
the public key of the signer (which must be known) and compare that with the
recomputed hash. If they match, the certificate is valid and has not been
tampered with.
Note the information required: The public key of the signer (typically a
Certification Authority or "CA") must be installed into the system using a
trusted mechanism. If the CA certificate is altered, the entire system can
be compromised.
I didn't really read the original requirement, but I recall it being
something along the lines of hiding a database schema. The basic principle
is this: If software in the user's environment can decrypt the schema for
use, and the user can examine state of the software while it is running, the
user can acquire the key and then acquire the information in the clear. As
Jim Starkey has pointed out, it might be obscure enough, but it isn't
security.
Controlling the environment through hardware can make things more secure: A
device with secure key storage with some cryptographic functions can help
ensure that the user can't observe the key. However, cost goes up,
usability goes down, and if you don't spend enough, performance goes down.
Jan Mikkelsen