Re: X.509 and ssh

Dimitri Maziuk <dima@xxxxxxxxx> writes:
The problems here are opening ldap server to the world, replacing
verisign with ldap server's administrator, standardizing use of
encryption which may be illegal in some jurisdictions, etfc. Never
gonna happen.

part of this can also be looked at from the security PAIN taxonomy

P - privacy (sometimes CAIN & confidentiality)
A - authentication
I - integrity
N - non-repudiation

encryption is frequently associated with P/privacy ... but can also be
used for integrity (i.e. at least being able to recognize
modifications in transit).

digital signatures can also be used as integrity countermeasure to
modifications as well as being used for A/authentication.

i've frequently claimed that the vast majority of encryption sessions
on the internet have been SSL associated with electronic commerce and
supposedly hiding (encrypting) an account number.

the threat issue is that leakage of standard account number enables
fraudulent transactions ... and is frequently lumped with identity
theft/fraud ... but there has been activity in the past couple years
attempting to strongly differentiate account fraud from identity fraud
(although both involve leakage of sensitive information for fraudulent
purposes).

the SSL activity around e-commerce and the original payment gateway
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

was supposedly both to authenticate the communicating website and hide
the account numbers. however, there has been lots of stuff attacking
the infrastructure at points other than the digital certificate part
of the operation. part of this might be attributed to certification
authorty industry embellishing the role of digital certificate as the
cornerstone of the security process ... as opposed as to one specific
mechanism that could used to implement one small piece of an
end-to-end secure business process .. i.e. ignore the digital
certificate and attack at some less well defended part of the
infrastructure ... one of my analogies has been installing a specific
kind of bank vault door in an open field w/o walls, ceilings, floors
.... and then trying to convince everybody that the only way of getting
what was behind the door was to attack the vault door.

now back to the early SSL activity
http://www.garlic.com/~lynn/subpubkey.html#sslcert

and attempting to hide (encrypt) account numbers during transmission.
for long before the internet, the major attack on account numbers has
been harvesting point-of-sale and/or backroom repositories (that
needed the account numbers for other parts of the business process)
.... frequently (some 70percent) by insiders. The encryption during
transmissioin was just to not create additional avenues for harvesting
account numbers. however, it ignored that havesting the backroom
repositories (that were in use by several backroom business process)
was still the major threat ... and just the fact that there was
internet connectivity created numerous additional threat avenues for
the major vulnerability (that the SSL encryption did nothing to
address) related to repository harvesting.
http://www.garlic.com/~lynn/subpubkey.html#harvest

that gave rise to my observation that even if you buried the world
under miles of encryption (and digital certificates), it wasn't going
to address account number leakage and account fraud.
http://www.garlic.com/~lynn/subpubkey.html#fraud

what x9.59 financial standard ... mentioned in the previous post
http://www.garlic.com/~lynn/2006c.html#34 X.509 and ssh

tried to do was to also eliminate account number leakage as a
vulnerability ... rather than trying to use constantly increasing
amounts of encryption in an attempt to prevent account number leakage
.... change the paradigm and create an environment where a leaked
account number is no longer threat/vulnerability for fraudulent
transactions.

one of the issues in the mid-90s was that there were some PKI-oriented
financial transaction protocol definitions; they would use a digital
signature for authentication/integrity along with an appended
relying-party-only digital certificate. however, they failed to create
a business rule that made account numbers used in digitally signed
transactions invalid when used in transactions that weren't digitally
signed. this met that account number leakage still presented a serious
account fraud threat and so also required that the account number
continue to be encrypted (in addition to using it in a digitally
signed transaction) ... aka this is the scenario where encryption
has to be used for things like shared-secrets
http://www.garlic.com/~lynn/subpubkey.html#secret

where divulging the information can result in fraud. the claim is if
you change the paradigm and the items can no longer be used
fraudulently, then the need for encryption is drastically reduced
(similarly encryption isn't the only solution if only integrity needs
to be addressed).

the other part was that since it was a relying-party-only certificate,
http://www.garlic.com/~lynn/subpubkey.html#rpo

the whole thing still had to be sent to the responsible financial
institution that was responsible for the certificate (and the
account). the financial institution pulled the account number from the
transaction and retrieved the account record ... which had all the
financial information as well as the originally registered public
key. the financial institution then validated the digital signature
with the public key in the account record. as a result the attached
digital certificate was totally redundant and superfluous.

it is actually slightly worse than totally redundant and superfluous.
the typical retail financial transaction size is on the order of 60-80
bytes and the mid-90s attached, relying-party-only certificate
overhead ran 4k to 12k bytes. not only was attaching the
relying-party-only digital certificate redundant and superfluous, it
also resulted in payload bloat of two orders of magnitude (100 times).

somewhat in response, the x9 financial standards group did start a
work item for compressed certificates ... hoping to get the size down
to on the order of 300 bytes (so it is only a five times payload bloat
instead of 100 times payload bloat for unnecessary, redundant and
superfluous certificates). one of the approaches was to establish that
all fields that were common to the relying-party-only certificates
could be eliminated (leaving only fields that were unique to a
specific digital certificate) on the assumption that the relying party
already had copies of all the common fields. I pointed out that if you
eliminated all digital certificate fields that the relying-party
already had copies of, digital certificates could be reduced to zero
fields and zero bytes. rather than saying that it was redundant and
superfluous to attach digital certificates ... it was perfectly valid
to attach zero-byte, compressed digital certificates.

note that the original observation is that the domain name
infrastructure is both

1) a technology; providing trusted, real-time, online distribution
of information

and

2) a business; providing trusted, real-time, online distribution of
information related to domain names.

it turns out that as a business, a public key can also be a perfectly
valid domain-name-associated piece of information and be distributed
in real-time (rather than requiring stale, static, redundant and
superfluous digital certificates to provide an association between a
domain name and a public key).

the issue with LDAP isn't so much that real-time, online distribution
of information isn't a valid implementation design (one can point to
search engines in addition to the domain name infrastructure as
another example of real-time, online information distribution
mechanism) ... it is just that LDAP designers possibly didn't give a
lot of thot in the protocol to attacks, threats, vulnerabilities, and
countermeasures.

for instance, it is possible for both LDAP and RADIUS to have
authentication, authorization, and account information in a backend
RDBMS database ... potentially a LDAP and a RADIUS deployment could
even share the same backend RDBMS database. There are RADIUS
implementation, deployments that support digital signature
verficiation as authentication mechanism
http://www.garlic.com/~lynn/subpubkey.html#radius

where the public key used to verify the digital signature is onfile in
the backend database (in lieu of current common deployments that used
RADIUS shared-secret, password mechanisms, where the shared-secret is
in the backend database).

I would assert that the problem isn't in the actual backend database
that might be used by LDAP (many deployments is frequently some RDBMS)
.... since there are examples of RADIUS protocol being able to utilize
essentially the same backend database.

Furthermore, domain name infrastructure protocol isn't tied to a
specific backend database implementation ... I would assert that it is
equally possible to create a domain name infrastructure deployment
that used a backend RDBMS database in similar ways to the way that
many LDAP deployments make use of backend RDBMS database.

and to complete the topic drift ... lots of posts about the
original relational/sql project
http://www.garlic.com/~lynn/subtopic.html#systemr
.

Relevant Pages

  • Re: How to securely store a password on a PC
    ... password - so locking the data to ONE account will not solve that problem. ... Full disk encryption can protect against EXTERNAL attackers (who ... full encryption - not only Vista's BitLocker but any 3rd party solution. ... Security is not about the secrecy of the algorithm. ...
    (microsoft.public.platformsdk.security)
  • Re: Encryption - Kerberos
    ... It might also be worth noting that Kerberos is not itself an encryption ... so the decryption which happens high up the stack in the ... Securing Apache Web Server with thawte Digital Certificate ...
    (Pen-Test)
  • Re: decrypt help...
    ... > i've tried re-establishing a user account with the same name as when i ... then importing the cert/key combo into that account ... You would need a backup of the user profile and machine system state as well ... >> a slippery slope that most stay as far away from encryption as possible. ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: EFS Certificates and Keys when Changing Password
    ... What that meant is that changing the password of the account only ... this case that the system will upon an encryption attempt generate a new ... Then I exported the certificate/key pfx file to a floppy disk. ... Then I encrypted more data files. ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Encryption - Kerberos
    ... It might also be worth noting that Kerberos is not itself an encryption ... so the decryption which happens high up the stack in the ... Securing Apache Web Server with thawte Digital Certificate ...
    (Security-Basics)