Re: Security flaw in how Outlook verifies digital signatures

From: Vanguard (use_ReplyTo_at_domain.invalid)
Date: 02/21/05 

Date: Mon, 21 Feb 2005 02:54:33 -0600

"Roberto Franceschetti" <roberto_remove_n.o.s.p.a.m_tag@logsat.com>
wrote in message news:c3eSd.98833$qB6.52566@tornado.tampabay.rr.com...
>
> ...And Vanguard, apparently I was too subtle in my explanation of what
> happened to my private key. I am a hacker, I send you an evil,
> infected, false, however bad you like, email, digitally signed. I also
> place *on purpose* my private key for download on a website and
> advertise it, so that when your lawyer tries to sue me, I'll say it
> can be any of the 10,000 people who downloaded my private key that
> could have sent it. I hope now you understand that talking about
> protecting my own key is futile, as I, the hacker, all that interested
> me was to spend $10 to get a valid certificate so I could cause harm
> using a digitally signed email, without being worried that what you
> thing is a unique and absolutely identifiable digital signature can be
> traced back to me. You see, I have the logs of the thousands of IP
> address who downloaded my private key... any one of them, especially
> the one from China and Korea, could have sent you the viruses...

Same with a fake driver's license. Same with a digital certificate.
Neither provide incontrovertible proof of your identity. Neither does
your birth certificate, your social security number, your school ID,
biometrics (can be faked if physical and signal security isn't provided
on the input device), and so on. Even your DNA could be spoofed: you
have an ID card with a copy of your DNA which is examined against your
living cell's DNA, yet the ID card is bogus because it is is a fake ID
that you created and implanted your own DNA, or you modified the lookup
database used to compare your tested DNA from your cells to what was
recorded in the database (akin to the scenario of when dental records
are replaced to make a body look like someone else). You were asking
for something equivalent to an ink signature, or maybe even better. As
I said, the 2004 revision of S/MIME to version 3 includes the ability to
include the sender information but I have yet to see any e-mail clients
that support it. Its use would also make impossible ever delivering any
of your e-mails except under very restrictive conditions because you
don't always send using the same mail server or even the same computer.
FedEx deliverying your signed documents doesn't change the fact the YOU
signed them, not FedEx.

What exists on this planet that is any more secure? Nothing you specify
cannot be faked and even perhaps more easily. In your scenario, you're
not even faking the certificate - but who said you couldn't fake your
identity when you got the certificate? One of the Windows Updates
itself includes copies of 2 certificates that were supposedly issued to
Microsoft but turned out to be someone else, so the certificates were
revoked but included in the updates so any lookup on those certs by
applications using them would show they had been revoked. Run the cert
manager (certmgr.msc) and check under Untrusted Certificates. There
they are. The update puts them on your computer to eliminate the need
to connect to the CA (certificate authority) to check them; otherwise,
you are expected to verify that they haven't been revoked (although the
client may do that for you automatically but obviously you need to be
online but, again just as obvious, you had to be online to yank the
e-mails, anyway).

Identity is not based on absolute certainty. It is based on a threshold
of [dis]belief. How much proof is proof? It is unimportant how you
arrived to the meeting to sign over the deed to your house. It is only
important that you provide *sufficient* proof of your identity once you
have arrived there to be granted to sign the papers. You make it sound
like there is some wonderful means of proving your identity that is
incontrovertible (i.e., that it could never be faked). And that would
be?

One of the reasons that certificates haven't caught on for reasonable
proof of identity (of content, not of delivery) is that users really
don't understand them. Just watch a user as they register and receives
a security certificate who then thinks they are going to use it to send
an encrypted e-mail to someone else, and then learns that they instead
need the public key from the recipient to get their certificate's public
key before the sender can encrypt the e-mail sent to that recipient.
You have yourself pointed out why users don't understand the purpose of
digital signatures. Security and ease-of-use are the antithesis of each
other.

Please explain how the sender information can be inserted into the
digital signature while *composing* the e-mail. You haven't sent it
yet. Even though the message/rfc822 information included in the
signature is supposed to include the sender information, that will only
be what is configured in the e-mail client and that is under control of
the user configuring that client. It is still NOT the information added
by the mail server or relay that sends the message. Identifying the
true sender is something in progress, but still that doesn't have to be
the same as the content author. Validating sender and validating author
are two separate tasks. Just because you and typical users confuse the
two doesn't alter what they are intended to be used for.

I can see that the documentation probably does need to be changed in
describing digital signatures. Users should be informed with a warning
that the use of a digital certificate only validates the author of the
content and NOT who or what sent it. As to your example of deliberate
misuse of a certificate, well, that applies equally to all other forms
of identification, too. While people have become accustomed to
differentiating a book publisher from the author of the work, apparently
they cannot fathom the same concept regarding e-mail delivery and
digital signatures. Telling users, in any e-mail client, that the
e-mail address in the certificate happens to match the e-mail for the
sender is not proof that the e-mail was not spoofed as to the sender nor
is it required that the sender be the author. You're comparing two
different identities and demanding they be the same. How could you ever
deliver any legal document if the same requirement were required for
postal mail?

Sender. Author. Different entities which might be the same but are not
required to be the same. Author has some threshold of proof of
identity. Sender [currently] has little or none. And you want the
client to equate these? That would be misleading. I wouldn't want any
e-mail client to equate these. If Outlook Express does it then THAT
client is in error. There is nothing wrong in provided a flag that says
they are the same but that does not equate one to the other nor does it
validate each other. It would be a "nice but not necessarily true"
flag, so it would be a worthless flag.

Relevant Pages

  • Re: Security flaw in how Outlook verifies digital signatures
    ... Although it is a warning, most users would interpret that as more than ... "Security Alert". ... between sender identity and author identity as should the documentation. ... the certificate icon alerts the user that the message has ...
    (microsoft.public.outlook)
  • Re: Digital Signature Standards
    ... tokens for digital signatures. ... well as every digital signature operation. ... encode it and digitally sign it; then package up the transaction, ... and the certificate and send it on its way to the financial ...
    (sci.crypt)
  • Re: Security flaw in how Outlook verifies digital signatures
    ... I use my own Verisign digital certificate to sign an ... > not warn him about the sender not being the one who signed the ... the sender info in the headers, ... source to validate the digital signature. ...
    (microsoft.public.outlook)
  • Re: Is symmetric key distribution equivalent to symmetric key generation?
    ... http://www.garlic.com/~lynn/2005o.html#31 Is symmetric key distribution equivalent to symmetric key generation? ... dealings with the sender, has no local repository about the sender ... the digital certificate is a stale, ... and the receiver has ...
    (sci.crypt)
  • Re: Digital Signatures
    ... Note also that some programming methods are disabled when you install a cert and tell the machine to use Sandbox mode ... (which is some of what you must do in order to avoid the security warnings). ... You can also build your own certificate, but in general that's not a great idea if you plan on ... There is a LOT of information about digital signatures, but these seem to help answer the most common questions: ...
    (microsoft.public.access.security)
Loading