« May 2006 | Main | July 2006 »

June 30, 2006

Think I could sign up for the Tour?

The Tour de France riders list has been more or less decimated due to accusations of blood doping (autologous transfusions rather than drugs, but still banned). Suspended riders include the two pre-race favorites, Ullrich and Basso. I guess it's too late for me to get in shape and sign up, though....

Posted by ekr at 9:53 AM | Comments (2)

June 29, 2006

RSTs and the Chinese firewall

Clayton et al. have a new paper about the Chinese content filtering firewall and how to defeat it. The basic observation is that the firewall doesn't actually block traffic that it doesn't like--that would require too much work on the part of the router--but rather forges TCP RST packets. If the endpoints ignore the RSTs then they can communicate without interruption.

Of course, RSTs aren't the only way to DoS a TCP connection. One obvious approach is to inject bogus traffic. If you're lucky and hit the HTTP headers (e.g., by forging packets immediately after you observe the SYN or SYN/ACK), this will cause one side to abort the connection. Interestingly, secure channel protocols can make the problem much worse: TLS, for instance, aborts the connection if it detects any MAC error (this is a common complaint about TLS but is pretty inherent in running it over TCP). You can, of course, make protocols that are much more resistant to this form of attack--IPsec for example, but it more or less has to be done below the TCP layer.

Posted by ekr at 6:58 PM | Comments (5)

June 28, 2006

Implications of Michigan's marijuana driving law?

The Michigan Supreme Court has upheld a law which makes it illegal to drive with any detectable amount of marijuana in your system. As Jacob Sullum points out, this is, kind of nuts. Marijuana stays in your system for days to weeks after you're no longer intoxicated. What I wonder about is the standard required for testing; in most states just by driving you're considered to have consented to chemical testing for alcohol. In the particular cases that are the the subject of this suit, there was evidence that the offenders had smoked marijuana, but I wonder if you can just be stopped and randomly tested.

Posted by ekr at 9:23 PM | Comments (1)

June 27, 2006

Tell me the one where you're going to block child porn again

News.com reports that AOL, EarthLink, Microsoft, United Online and Yahoo are going to cooperate to block child porn.
The system works like this: When AOL employees become aware of a child pornography image included as an e-mail attachment, they forward the attachment and information about the sender's geographic location to the National Center for Missing & Exploited Children, which in turn sends it to the appropriate law enforcement agency. AOL also generates a digital fingerprint of the image so it can be automatically flagged if it flows through the company's network in the future.

...

Another possibility, Schoen said, is that child pornographers who know how the system works would simply make a tiny tweak to photographs to avoid detection--rendering the hash detection system useless. Internet providers could counter-attack using a "locality sensitive hash" function that's designed to detect similar files, but even that in turn could be foiled if image files are encrypted.

Schoen is quite right, of course. Cryptographic hashes are particularly poorly suited to this problem because the whole point is for them to be sensitive to even single-bit errors. There certainly are fuzzier hashes but pretty much any hash function you use is going to be easy to defeat by even simple non-cryptographic transformations in the data, let alone by encryption.

There are two challenges to making an encryption scheme work here. The first is that because ciphertext is so high entropy it's generally fairly easy to detect. The good news is that compressed images in general are very high entropy anyway, so ciphertext is fairly easy to hide there using standard steganographic techniques work. There are techniques for detecting steganography but they're not superfast and the job can be made arbitrarily difficult if you're willing to accept a suitably low coding rate.

The second challenge, is to design a scheme that doesn't require the communicating parties to exchange cryptographic keys. You could of course just carry the key in the message. This would still produce a basically random ciphertext which would defeat simple hash matching--until the ISPs reverse engineer your data format and figure out how to extract the encryption keys that is. However, there's a simple workaround use a short encryption key (say 24 bits or so) but don't put it in the message. The recipient just exhaustively searches the key space, which doesn't take long. Obviously, the ISPs could do the same thing but they're at a very severe disadvantage because they have to scan every candidate message--which is basically impractical--whereas you just need to scan the ones sent to you.

Posted by ekr at 9:59 PM

June 26, 2006

Viagra???

CBS News reports that Rush Limbaugh has been detained at the Palm Beach Airport:
CBS4 News) WEST PALM BEACH Sources have confirmed to CBS4 News that conservative talk show host Rush Limbaugh has been detained at Palm Beach International Airport for the possible possession of illegal prescription drugs Monday evening.

Limbaugh was returning on a flight from the Dominican Republic when officials found the drugs, among them Viagra.

Limbaugh entered a plea deal back in April in a previous case where his charge of fraud to conceal information to obtain prescriptions was dropped under the condition he continue undergoing treatment for addiction.

What's weird about this story is that Viagra isn't at all hard to get legally. If you're too embarassed to ask your doctor, lots of online pharmacies will "diagnose" you, write you a scrip for the Erectile Dysfunction meds of your choice (this variety pack is pretty clever), and ship them to you FedEx. Now, it's true that Internet pharamacies are a bit of a gray area, but it's not like you're going to get arrested for it. So, why would you bring in drugs from outside the country, which is pretty clearly (illegal), though seldom prosecuted.

Now, this would make more sense if the drugs in question were opiates, which are in general harder to get and probably even harder for Limbaugh, given his history. But if he was bringing in opiates, why don't the news reports say anything about them? Very puzzling.

UPDATE Turns out that the story is that his prescription was in his doctor's name, apparently for privacy purposes. Probably not the best decision.

Posted by ekr at 7:11 PM | Comments (2)

June 25, 2006

Trail report: Lost Valley Trail

Date hiked: June 16-18
Sections hiked: Escondido Camp to Higgins Camp
General condition: Difficult

The descent from Escondido to Arroyo Seco is clear with obvious tread. The river crossing is fine but getting back on the right trail afterwards is a bit tricky. The section from Escondido to the ridge line is in reasonably good shape with clear tread. Descending to Fish Camp, the trail gets increasingly overgrown and after Lost Valley Camp you have to push through brush about half the time. Both of us ended up with scratches all up and down our arms. Based on the rather complete spider webs on the trail, it looks like it's not getting much use. The trail improves a little bit between Pelon and Higgins, but it's not still fairly bad.

Posted by ekr at 9:38 PM | Comments (2)

June 23, 2006

What do you expect MySpace to do?

In response to criticism over adult/child contact, MySpace is instituting some new security measures:
In trying to allay the public, MySpace.com, which is owned by Rupert Murdoch's News Corp., put in place Wednesday added security for 14- and 15-year-old members, new options for privacy settings for all members and restrictions on ad placements to teens.

"MySpace is committed to innovating new product features to heighten online safety, particularly in the area of 14 to 15 year olds," Hemanshu Nigam, chief security officer for MySpace.com, said in a statement. "In addition to technology innovation, MySpace remains dedicated to a multi-pronged approach that also involves education and collaboration with law enforcement, teachers, parents and members."

MySpace.com recently hired Nigam, a former federal prosecutor against Internet child exploitation for the U.S. Department of Justice, to oversee its child protection measures.

The added security features include preventing a person 18 or older from contacting a member under 16 years old, unless he knows either the email address or first and last name of the minor.

I understand that people are concerned that adult "predators" will contact children on MySpace, but it's hard to believe that this is really going to work, depending, as it does, on voluntary compliance on both sides. If you're an adult looking to have sex with children (illegal, remember) then it's not like you're going ot mind lying about your age. On the flip side, if 14 and 15 year olds want to talk to adults and be taken seriously (which I remember wanting to do when I was under-16) they're likely to lie about their age, no? Absent some sort of externally verifiable age verification system, it's hard to believe that MySpace can really do much enforcement.

Posted by ekr at 9:10 PM | Comments (1)

June 21, 2006

Life imitates art (the West Wing Explains American Politics)

The West Wing Episode 1: Pilot (reformatted):
Mary: I dont like what Ive just been accused of.

Toby: [raising his voice] I'm afraid thats just tough, Mrs. Marsh.

Van Dyke: The First Commandment says "Honor thy Father".

Toby: No it doesnt.

Josh: Toby--

Toby: It doesnt.

Josh: Listen--

Toby: No, if I'm gonna make you sit through this preposterous exercise, were gonna get the names of the damn commandments right.

Mary: Okay. Here we go.

Toby: "Honor thy Father" is the Third Commandment.

Van Dyke: Then whats the First Commandment?
A booming voice comes from off screen. The camera moves to show PRESIDENT JED BARTLET with a cane standing in the doorway with several Secret Service agents.

President Jed Bartlet: "I am the Lord your God. Thou shalt worship no other God before me." Boy, those were the days, huh?

Congressman Lynn Westmoreland on the Colbert Report:

Colbert: You co-sponsored a bill requiring the display of the Ten Commandments in the House and the Senate. Why was that important to you?

Westmoreland: Well, the Ten Commandments is not a bad thing for people to understand and respect.

Colbert: I'm with you.

Westmoreland: Where better place could you have something like that than in a judicial building or in a courthouse?

Colbert: That is a good question. Can you think of any better building to put the Ten Commandments in than in a public building?

Westmoreland: No. I think if we were totally without 'em we may lose a sense of our direction.

Colbert: What are the Ten Commandments?

Westmoreland: What are all of them? You want me to name 'em all?

Colbert: Yeah. Please.

Westmoreland: Don't murder. Don't lie. Don't steal. Uh... I can't name 'em all.

Colbert: Congressman, thank you for taking time away from keeping the sabbath day holy to talk to us.

Posted by ekr at 10:37 PM | Comments (1)

June 20, 2006

North Korea is ready to beta test NMD

Forbes reports that the Bush Administration is considering responding to North Korea's impending missile test by trying to shoot down the missile.
The Bush administration is weighing responses to a possible North Korean missile test that include attempting to shoot it down in flight over the Pacific, defense officials told The Associated Press on Tuesday.

Because North Korea is secretive about its missile operations, U.S. officials say they must consider the possibility that an anticipated test would turn out to be something else, such as a space launch or even an attack. Thus, the Pentagon is considering the possibility of attempting an interception, two defense officials said, even though it would be unprecedented and is not considered the likeliest scenario.

The officials agreed to discuss the matter only on condition of anonymity because of its political sensitivity.

Pentagon spokesman Bryan Whitman said he could not say whether the unproven multibillion-dollar U.S. anti-missile defense system might be used in the event of a North Korean missile launch. That system, which includes a handful of missiles that could be fired from Alaska and California, has had a spotty record in tests.

The first thing you need to know here is that although this is being pitched as the DPRK testing a missile that has "sufficient range to reach U.S. territory", what we're talking about is a Taep'o-dong 2 (TD-2), with a range of under 3000 miles according to FAS. It's about 3700 miles from Pyongyang to Anchorage (pop 260,000), so even Alaska is pushing things pretty substantially. We're not talking about the DPRK nuking LA here.

The second thing you need to know is that the US "missile shield" doesn't work in what you'd call a reliable kind of way, even in pretty favorable tests, and hasn't really been tested at all in situations where the missile isn't cooperating. Sure, we might hit some missile fired by North Korea, but it's not something you'd want to bet money on.

Now, obviously if we know that the DPRK has launched a missile that's intended to land in the US, then it's worth trying the defense system. Even if it doesn't work, what's there to lose. But based on my imperfect understanding of the technology and the news coverage, it appears that at the point where we have to make the decision, we can't tell enough about the targetting to know one way or the other.

Given that assumption, let's do the case analysis here. Either the DPRK is up to something more nefarious than a missile test or it's not. If they're not up to something nefarious and we don't try to intercept the missile, then they get to test their missile and the US look slightly weak. If we do try to intercept the missile and it works, then the US gets to look tough and it provides some deterrent against future ballistic missile attack. On the other hand, since single-missile attacks are stupid (more on this later), it's not much of a deterrent. On the other hand, if we try to intercept the missile and the defense system fails (which is the most likely case), the US looks stupid and it confirms what people already expected; that the missile defense system doesn't work.

Now consider the case where the DPRK is up to something nefarious. Maybe Kim Jong Il is afraid of grizzly bears or is pissed he never got to compete in the Iditarod. Anyway, they decide to attack Alaska. If we don't attempt to intercept the missile, it either works or it doesn't work (e.g., doesn't reach the US or misses or something). If it doesn't work but it's clear that they tried to attack us, we presumably attack the DPRK, which surely isn't something they think it's desirable. If it does work, we almost certainly attack the DPRK. Given that the DPRK has nukes and could attack us in a much simpler, effective, and most importantly deniable fashion by shipping a nuke into one of our ports, it's hard to see why they would take this particular tactic.

Finally, consider the cases where they're up to something nefarious and we do try to intercept. If it doesn't work, then we're back to the cases in the previous paragraph. If, on the other hand, by some miracle it works, then we've managed to save the land of the midnight sun. Congratulations!

Obviously, you can assign your own probabilities to these cases, but it seems to me that this decision requires weighing the very small chance of a good outcome (the chance that we're actually being attacked times the chance that the the system will work) against the very high chance of looking incredibly stupid if the system doesn't work.

Posted by ekr at 9:59 PM | Comments (2)

Beat, beat, and beat again

WaPo reviews Ron Suskind's One Percent Doctrine (þ Jack Balkin):
Which brings us back to the unbalanced Abu Zubaydah. "I said he was important," Bush reportedly told Tenet at one of their daily meetings. "You're not going to let me lose face on this, are you?" "No sir, Mr. President," Tenet replied. Bush "was fixated on how to get Zubaydah to tell us the truth," Suskind writes, and he asked one briefer, "Do some of these harsh methods really work?" Interrogators did their best to find out, Suskind reports. They strapped Abu Zubaydah to a water-board, which reproduces the agony of drowning. They threatened him with certain death. They withheld medication. They bombarded him with deafening noise and harsh lights, depriving him of sleep. Under that duress, he began to speak of plots of every variety -- against shopping malls, banks, supermarkets, water systems, nuclear plants, apartment buildings, the Brooklyn Bridge, the Statue of Liberty. With each new tale, "thousands of uniformed men and women raced in a panic to each . . . target." And so, Suskind writes, "the United States would torture a mentally disturbed man and then leap, screaming, at every word he uttered."

Outstanding!

Posted by ekr at 8:59 PM | Comments (1)

June 19, 2006

Notes on Web authentication enhancements

There's obviously a lot of interest in working on various enhancements
to Web and Web Services applications. Unfortunately, after reading
the various drafts and mailing list postings produced by the proponents
of various technologies, I don't come away with the sense that people
have a common view of what is needed. This message is a first cut
at a taxonomy of requirements/features and technical options.


BACKGROUND: THE CURRENT STATE OF HTTP AUTHENTICATION
----------------------------------------------------
HTTP has two native authentication mechanisms, Basic Authentication
(passwords in the clear in an HTTP header) and Digest Authentication
(a challenge-response handshake also in the HTTP header). Both
mechanisms depend on the client proving the possession of a shared
secret string (a password in all real cases) to the server. The
server is unauthenticated.

For a variety of reasons, including bad UI on the clients, nearly
all real-world Web applications use neither mechanism but rather
use an HTML form to prompt the user for his password. This
password is then sent in the clear over the HTTP connection.
The standard security advice for how to secure this data is to
use HTTPS (HTTP over SSL/TLS) to encrypt the entire channel
and use the server's certificate to authenticate the server.
Practical difficulties with checking the certificate have led
to phishing attacks, in which the attacker gathers the user's
password and can then impersonate the user. An additional problem
is that it's hard for Web Services apps (e.g., DAV) to use this
kind of mechanism because HTML may not be involved and so if 
it works at all you end up resorting to screen-scraping.

In principle, if you run HTTPS, you can leverage HTTPS's 
client authentication mechanisms (client certificates and
"pre-shared keys") to authenticate the client, but in practice
this is not done, probably due to UI reasons and lack of
familiarity with the TLS mechanisms (this applies in particular
to PSK).



DESIRABLE FUNCTIONALITY
-----------------------
As I mentioned above, a lot of different types of functionality
have been discussed. In this section, I try to break these down
into a set of somewhat independent functions, with the intention
that we can end up saying that we want a system that provides
function X and not Y. These all have sort of lame names that I
thought of on the spot.


1. Capture-Resistant Credentials (CRC)
Credentials which are designed so that if you authenticate
to relying party (RP) X, X cannot use them to impersonate you to RP Y
(even if your intention was to go to Y). Phishing is based
on the fact that passwords do not have this property.
The rationale for this feature is to make phishing-type
attacks difficult.

2. Hijack-Resistant Authentication (HRA)
An authentication system in which credentials which are bound to
protocol messages in such a way that attacker who observes the
credentials can't use them to authenticate messages of their
choice. The rationale for this feature is to make cut-and-paste
attacks difficult.

3. Portable Credentials (PC)
The nice thing about passwords is that you can memorize your
password and then use it anywhere. The rationale for this is 
to make it easy for people to use credentials on multiple
computers.

4. Fill-in of Personal Information (FPI)
One of the common complaints about Web form registration systems
is the need to repeatedly type in your user information. Think of this
as automatic form fill-in on steroids. The rationale for this
feature is to avoid repeated typing of this kind of information.

5. Common User Credentials (CUC)
One way to limit the damage from credential compromise is to
have each RP use a separate credential and force the user
to make them independent (e.g., a separate password for each
RP.) This is inconvenient, of course. CUC means that at
the number of separate credentials that the user handles is 
small (if not 1). The rationale for this feature is to minimize
user attention and storage overhead.

6. Continuity of Identity (CI)
The ability to prove to some RP that you are the same
user as was involved in some other transaction. The rationale
for this feature is to have a cheap form of personal 
"account" for systems like blog comments, message boards,
etc.

7. User-Friendly Names (UFN)
The ability to prove possession of some non-random-appearing
name. The reason to separate this out is that one natural
way to provide CI is simply to generate some random asymmetric
key pair and use that (or its digest) as your identity. This
name is not user friendly. Note that this is the first requirement
in this list that appears to require a third party (to assign
the names). The rationale for this feature is that random names
are hard to remember.

8. Assertion of External Claims (AEC)
The ability to demonstrate some real-world fact about the user
(e.g., I am a certain age, this is my address, etc.) to the
RP. The rationale for this feature is that there are contexts
in which the relying party needs to be able to establish this
sort of information.

10. Independent Assertion of Claims (IAC)
The ability to assert claims independently so that the user
could (for instance) demonstrate their age to the RP without
without revealing their address. The rationale for this
feature is to protect the user's privacy.

11. Private Authentication (PA)
Some third-party authentication systems require an interaction
with the 3rd party for each authentication. In some such systems,
the 3rd party knows the relying party for each authentication
and the claims which were asserted. PA means that the 3rd party
does not get that information. The rationale for this feature
is to protect the user's privacy from the 3rd party.


ARCHITECTURAL CHOICES
---------------------
In this section, we survey a number of potential architectural options.
This list isn't exhaustive, but is just intended to give a flavor
of the major available choices beyond the simple two-party
username-password schemes we have now. Note that I use a lot 
of PKIX-type terminology below, but the concepts are generic
and can be extended to something more SAML-oid or
something-else-oid.


BARE CRYPTOGRAPHIC IDENTIFIER 
After username/password, probably the most familiar sort of
remote identifier is a bare public key. The way this is
used is familiar from SSH: the user generates a public key
and provides the key (or fingerprint) to the relying party
(or parties). He can then sign with the private key to
prove possession.

User                                     RP
----                                     --
[Personal Info], K_pub ->                        \  Registration
                                      <- OK      /  Phase

Sign(K_priv, Something) ->                       \  Use 
                                 <- Service      /  Phase

In the Registration phase, the user provides his registration info
to the relying party (site) along with the public key. The
RP stores the data somewhere. In the Use phase the user signs
something with his key to prove his identity.

Properties:
If properly embedded in a protocol (it's easy to get this wrong),
this scheme can provide:

CRC -- the RP only has K_pub
HRA -- you can cryptographically bind the requests to the key
CUC -- you can use the same K_pub, K_priv pair over and over
CI  -- you use the same identity every time even if nobody
       knows who you are.
PA  -- there's no third-party to know anything about the
       exchange

With an automated form fillin scheme like that specified in DIX,
you could also provide FPI. 


IDENTITY CERTIFICATES
One of the major inconveniences in dealing with bare cryptographic
identifiers is that that names look basically random: they're
just public keys or hashes of public keys. This is a particular
problem if two RPs want to communicate about a user through
some human-based protocol, i.e., "Don't trust bob@example.com"

The natural way to deal with this problem is to have certificate
authorities which are responsible for sections of the namespace and
can issue certificates with user-friendly names.

These certificates can come in two flavors:

1. Real-world identity certificates.
2. Unique-identity certificates

Real-world identity certificates are familiar from the HTTPS
world: an SSL certificate from VeriSign is an assertion that
the certificate holder is the actual owner/operator of a
given domain. A unique-identity certificate is just a promise
from a CA not to issue any other certificates with the same
username. 

Either form of identity certificate allows you to have nice
userfriendly names (or at least more userfriendly than random
numbers). The protocol looks something like this:

User                                     CA
----                                     --
[Personal Info], K_pub ->                        \  Certificate
                                      <- OK      /  Issuance


The user gets a certificate (possibly covering some personal
info) from the CA. They can then use this certificate much
in the same way they used a bare key, by registering with
the RP and then getting service. 

User                                     RP
----                                     --
[Personal Info], Cert ->                         \  Registration
                                      <- OK      /  Phase

Sign(K_priv, Something) ->                       \  Use 
                                 <- Service      /  Phase

Note that some people also think of the mere possession of a
credential, even if it has no underlying AEC semantics as
worth something. I.e., this person registered *somewhere*
and I know that about them. This makes sense in contexts like
blog comment authentication where you are just trying to erect
a minimal registration barrier.


Properties:
This scheme has most of the same properties as the bare cryptographic
identifiers, but also has at minimum User Friendly Naming (UFN).
In addition, if the certificates are real-world identity certificates,
it provides a very limited form of AEC, namely "this person has
the right to this e-mail address, domain name, etc."


SIGNATURE + KEY SERVER
Both bare cryptographic identifiers and identity certificates suffer
from portability problems. The part of your identifier that you need
available to you at authentication time is a fairly long random number
that most people won't be willing to memorize. [0] The natural
approach is to carry the data around on a token (USB key, PCMCIA
card, etc.) but this seems unattractive to many. Another option is
to use a SACRED-type server to store the key and then let the user
fetch it at whatever computer they are at. SIP is also considering
a similar technique for moving keys between handsets (see
(draft-ietf-sip-certs)

Properties:
Same as underlying authentication scheme + Portable Credentials.


ATTRIBUTE CERTIFICATES
The clear problem with all the schemes mentioned so far is that
they only provide very limited AEC, which a lot of people clearly
want. The standard solution for combining AEC with public-key-based
authentication systems is to use attribute certificates: 
certificates that assert a certain fact about the holder of key
K, such as:

"The person who holds key K is an American citizen."

In PKIX these are often (always?) tied to some actual 3rd-party
certificate but from an architectural perspective, they could be tied
to a bare key. Attribute certificates can also be used to provide
IAC: you have a bundle of attribute certs with one for each claim
you wish to assert and you simply provide the relevant certs
to the RP.

The basic protocol looks like this:


User                                     CA
----                                     --
[Personal Info], K_pub ->                        \  Certificate
                           <- AC1 (Over 21)       > Issuance
                        <- AC2 (US Citizen)      /


In the Certificate Issuance phase, the user proves to the
CA the claims that he wants the CA to vouch for and the 
CA gives him ACs for those claims. 

User                                     RP
----                                     --
Sell me beer ->                               \
                         <- Prove you're 21    \ Use
Sign(K_priv, Something), AC ->                 / Phase
                                 <- Service   /

In the use phase, the RP indicates which claims he wants the
user to demonstrate and the user provides the appropriate
ACs and demonstrates that he has the corresponding key. 
Of course, for any attributes for which you have ACs, you
also get some FPI for free as part of the authentication.

Properties:
CRC, HRA, FPI (Some), PC (if used with key server), CUC, CI,
UFN, AEC, IAC, PA


IDENTITY PROVIDERS
A lot of the designs that people seem interested in involve
Identity Providers (IdP). An IdP is a server that offers
interactive identity claims. (One way to think of this is
as a real-time CA). There are a bunch of different 
topologies, but the basic idea is as below:

User                           IdP
----                           ---
[Personal Info], Auth Info ->       \  Registration 
                             <- OK  /  Phase     

The user registers with the IdP and (optionally) proves
the claims that he wishes the IdP to assert later. The
user needs to establish some sort of authentication
credential with the IdP so that he can authenticate
later. This can be a password or a public key pair (as
above). 

Later, when he wants to actually use his identity, we
get an exchange like this:


User                      RP                       IdP
----                      --                       ---
Sell me beer ->                                         
          <- Prove you're 21

IdP, help me!                                   ->
          <---------- Auth exchange ------------->
                                         <- Credential

Credential ->              
                       <- OK
                      
When the user requests service, the RP prompts them for their
identity (or in the case above, to prove some claims). The
User then contacts the IdP and proves their identity 
(authenticates as the person who previously registered)
and gets a credential. He Then provides the credential to the
RP, who provides the service. 

There are a lot of ways to implement this general architecture
and they all have different properties. 

Properties:
At minimum, IdP based schemes provide:
PC  -- you can contact the IdP from anywhere
CUC -- you only need to authenticate to the IdP and then can 
       leverage that to authenticate everywhere
CI  -- you use the same IdP acct over and over
UFN -- the IdP can issue you some easy name

If the IdP makes claims about you, then you can also have FPI, AEC and
IAC. In general, because the IdP knows which claims you're asserting
for a given RP, you do not get PA. There are, however, ways to provide
this feature, but often the contrary is part of the design of the
system.

A lot of the variation in IdP schemes is the implementation of 
the authentication, both from the user to the IdP and from the 
IdP (and user) to the RP. There's too much variation to discuss
here, but I'll cover a few high points.


Authentication to the IdP:
Part of the point of an IdP scheme is that you authenticate to
the IdP in order to get your credentials. Obviously, this 
authentication can be done in a lot of ways. Some of them
allow phishing, credential capture, etc. It's clearly
desirable to couple an IdP scheme with some sort of
auth scheme that provides CRC and probably HRA.

Binding of credentials to requests:
In an IdP scheme, the IdP provides some token to the user that is then
provided to the RP. This token may or may not be cryptographically
bound to the messages that the user is sending to the RP. If this
is not done, then the user<->RP protocol is potentially susceptible
to hijacking.

Note that it's well understood how to design both of these protocols
securely. However, it involves more changes to the current
implementations of Web and WS protocols.


TRANSPORTING/BINDING CREDENTIALS
--------------------------------
The discussion above has focused primarily on dataflow, but
from the perspective of implementation/deployment, how you
transport and bind the credentials to the PDUs they're 
authenticating matters. Note that to some extent this is 
orthogonal to the type of authentication architecture you're
using. You can, for instance, use public key signatures
with multiple binding/transport mechanisms. 

There are three commonly proposed transport/binding methods:

CRYPTOGRAPHIC BINDING INSIDE HTTP
If you're using public key for authentication, the natural approach is
to simply have the credentials bound directly to the HTTP PDUs they
vouch for. So, the PDU would contain a signature line that covered the
request itself. This is what, for example, S-HTTP does.

In systems like this, additional credentials (ACs, SAML assertions,
etc.) are just carried in the message and the whole thing is bound
together with the signature. Something like this:

         POST / HTTP/1.0
         X-Attribute-Cert: 
         X-Signature: XXX

         Post arguments

The signature is computed over the entire message and headers (except
for the signature itself, of course), or part of it (hopefully enough
to block cut-and-paste attacks).  This kind of technique, if performed
correctly, provides both CRC and HRA for the messages between the user
and the RP.

Similar techniques can be use with symmetric keys and MACs over
the PDUs. In such schemes, if you're using an IdP, then you'll
probably also have to carry around a ticket that gives the 
RP the symmetric key needed to verify the message.

Implementing this kind of scheme would generally require a fair
amount of modification to the browser and server at least to
protect the messages. 


SSL/TLS CLIENT AUTHENTICATION
Another approach is to do things at a layer below HTTP, typically
using SSL/TLS client authentication. Currently, SSL/TLS supports
client authentication using pre-shared keys and certificates (you can
use self-signed certs as bare keys).  draft-housley-tls-authz-extns
defines how to carry X.509 ACs and SAML assertions inside of TLS, so
these could be used as well. This technique automatically provides CRC
and HRA.

In principle, TLS clients and servers already support at least
cert-based client auth. In practice, the UI on the client
is so bad that you would almost certainly need to clean it up
quite a bit in order to make this kind of system usable.


CARRIED NONCRYPTOGRAPHICALLY INSIDE HTTP
One approach that comes up quite a bit is to just embed 
authentication tokens (typically generated by an IdP) in
the HTTP messages that go from the user to the RP (DIX is
an example of such a scheme). In this system, the tokens
themselves are "bearer"--they enable any holder to impersonate
the user. In order to protect against token capture, the tokens
are generally made specific to the RP, so that one RP can't
use them to impersonate the user to another. 

An additional issue is hijacking: without cryptographic 
binding, an attacker who observes a request can make future
requests in the name of the user via a cut-and-paste attack
(remember, the token is bearer). If you take the threat of
this type of attack seriously, you need to run the traffic
over SSL/TLS. [1] 

The primary attraction of this kind of design is that it
may be implementable without changing the client software
at all (again, see DIX). Many people see that as important
for deployment. 


[0] You can use asymmetric key pairs generated from passwords,
but even with the application of key stretching techniques, this
makes a lot of people uncomfortable.

[1] Note that if you're worried about this class of attack, you need
*every* PDU to be cryptographically bound to the credential with
all designs. If, for instance, you use cert-based auth but then
transition to cookies over HTTP for state management, there's a 
cut-and-paste attack there.

Posted by ekr at 5:53 PM | Comments (4)

June 18, 2006

Some background reading on poison ivy

Following up on Scott D's comment recommending Zanfel, I found this very interesting review article on poison ivy-induced dermatitis. Probably the most interesting bit is:

Systemic steroids are the standard treatment for severe Toxicodendron dermatitis. The typical dose of oral prednisone is 0.5-2.0 mg/kg/day (usually 1.0 mg/kg/day) tapered over a 14-21 day period.2, 6, 8, 34 Based on the results of one study,50 three-weeks is a reasonable duration, although this aspect of treatment is debated. If steroids are stopped earlier than 14 days after onset of dermatitis, the eruption will "break through".3 Alternatively, intramuscular triamcinolone acetonide, 1.0 mg/kg, naturally tapers over 3-4 weeks and, in the author's experience, compliance is 100%,35 and there are less acute side effects such as emotional lability, water retention, hyperactivity, and increased appetite. Rare side effects of corticosteroid use include exacerbation of gastric ulcers, diabetes, hypertension, and rarely, avascular necrosis of the hip.49 Corticosteroids decrease inflammation by reversing increased capillary permeability and by suppressing neutrophil activity. Corticosteroids reduce itching by inhibiting a delayed type hypersensitivity response.

...

While systemic steroids are extremely effective when indicated, it is common for patients to seek further treatment for Toxicodendron dermatitis after receiving a dosepak of methylprednisolone. This 6-day treatment regimen contains the equivalent of 30-25-20-15-10-5 mg of prednisone on each of the six days. This is a lower and shorter dose than will effectively treat Toxicodendron reactions.8, 49 The dermatitis 'recurs' because it requires at least 3 weeks to run its course,50 and stopping the steroids merely allows the natural disease to "come out of hiding."

This appears to be a fairly common mistake. I've been prescribed dosepaks before, and at least once noticed the rebound effect. Clearly this is something to mention if you have to go to the doctor for steroid treatment. The only article I was actually able to get a copy of was:

Brodell RT, Williams L. Taking the itch out of poison ivy. Are you prescribing the right medication? Postgrad Med. 1999;106:69-70.

This article cites a bunch of others (note that I haven't been able to actually get copies of them):

Ives TJ, Tepper RS. Failure of a tapering dose of oral methylprednisolone to treat reactions to poison ivy. JAMA 1991;266(10):1362
Baer RL. Poison ivy dermatitis. Cutis 1986;37(6):434-6
Wooldridge WE. Acute allergic contact dermatitis: how to manage severe cases. Postgrad Med 1990;87(4):221-4
Funk JO, Maibach HI. Horizons in pharmacologic intervention in allergic contact dermatitis. J Am Acad Dermatol 1994;31(6):999-1014

To make things even better this article claims that oral antihistamines don't help the dermatitis at all (there's actually a controlled trial indicating that they don't) though they may make it easier to sleep. As I've long suspected, neither does 1% hydrocortisone cream. Hydrocortisone cream + oral antihistamines is of course the standard treatment you get if you show up at your doctor with poison ivy. Topical antihistamines don't work either.

As for Zanfel, there's a single controlled trial that indicates that it works early on and an apparently uncontrolled one that indicates that it works four days after exposure. I don't have any reliable anecdotal data one way or the other.

Posted by ekr at 9:40 PM | Comments (3)

June 16, 2006

Short Vacation

I'll be out in the Ventana Wilderness through Sunday. Blogging should resume then, assuming I'm not eaten by poison oak.

Posted by ekr at 10:32 AM

June 15, 2006

Fluticasone now in generic, sort of

Flonase, one of the first line corticosteroid nasal sprays (for allergic rhinitis, etc.) is now available in generic from PAR pharmaceutical. When you look on the box, though, you notice something interesting: it's actually made by GlaxoSmithKline, the people who make Flonase: [*]:
First-quarter sales growth was driven by fluticasone propionate nasal spray. In February, Par announced that it entered into a supply and distribution agreement with GlaxoSmithKline (GSK) in the U.S. to distribute the product. Fluticasone propionate nasal spray is fully substitutable for GSK's allergy spray Flonase and is manufactured by a GSK subsidiary. After a restraining order temporarily halted distribution of generics, shipments of Par's product resumed in March. In the first quarter, fluticasone achieved sales of $57.8 million.

I'm not an expert on generic drugs, but my impression was that mostly the manufacturing was done in different plants operated by the generic manufacturers, rather than by the original patent-holder. Of course, you can still buy Flonase at a rather substantial markup. I believe this is what's known as "price discrimination".

Interestingly, generic Flovent (the inhaled aerosol version of the same drug) does not appear to be available yet. I wonder if this has anything to do with Flovent changing their propellent over from CFCs.

Posted by ekr at 10:10 AM | Comments (2)

June 14, 2006

Building a privacy-protecting contactless card query protocol

One of the big concerns people have about RFID systems such as RFID passports is that they leak identity information. In your most simple RFID protocol, the reader sends out a probe signal and the transponder (passport, tag, etc.) responds with its stored data. In the case of a price tag, it's some sort of identifier for the product and likely a unit-specific number. For a passport, it's your name, biometric information, etc. This protocol has two main drawbacks. First, any passive observer can capture your information. Second, anyone who can build or buy a reader can capture it.

The simplest fix for this is to encrypt the data on the token using some static key known to all the readers in an organization. This partially solves the problem of someone buying a reader on the open market--since they won't have the right key, but only partially. First, since the encrypted data is static, you can still track people even if you can't read their data. Second, it's subject to a catastrophic failure mode: if the attacker can get a reader with a valid key--or just the key--then he can decrypt the data. Nevertheless, this is the best we can do with a memory-only card. 1

If you're willing to do processing on the token, then you can do somewhat better: the reader provides its public key certificate. The token verifies the certificate and encrypts under the public key. This stops the tracking problem for readers without the key, but not for readers with the key. And since any reasonable-sized organization will have lots of readers, the probability that one will go missing is fairly high. In order to contain this, you need some kind of process for revoking readers, which makes life massively more complicated.

1.One exception is that if we have a side channel, we can encrypt the data with a per-token key communicated via the side channel. This has been proposed for passports (having the key printd on the passport) but doesn't really work for lots of applications, since much of the point of contactless cards is to avoid having to have such a side channel.

Posted by ekr at 9:47 PM

June 13, 2006

Thank you MPAA

As I discovered today while sitting down to watch Transporter 2, the MPAA has decided to subject us to some free propaganda about how downloading movies is stealing. Better yet, they've marked the stop key (and fast forward, etc.) a user prohibited operation, so you can't skip past it. On the other hand, I did borrow the movie from a friend, which would probably be illegal if they had their way.

Posted by ekr at 9:36 PM | Comments (4)

June 12, 2006

Security of contactless smartcards

Schneier points to an article by Helena Handschuh from smartcard manufacturer Gemplus about how contactless smartcards (aka RFID) are no less secure than ordinary contact smartcards. Most of the paper focuses on the comparative difficulty of using side channel attacks to extract keying material. I'm not saying this isn't an important attack, but it's not clear it really represents the right threat model.

The concern that most people have about contactless cards isn't that they're going to be cracked but rather that they can be used to compromise your privacy: the attacker probes your card and gets it to identify itself and so at minimum you can be tracked. Cryptography can be used to protect against this to some extent (though actually getting it right can actually be quite tricky) and you can also store your contactless card in a RF shielded container (typically an aluminized mylar bag) but it's not really an issue for ordinary smartcards, which need to make physical contact with the reader. So, I don't really think it's fair to say that contactless smartcards are no inherently less secure.

Posted by ekr at 7:51 PM | Comments (1)

June 11, 2006

Notes on plugins and shared libraries

One of the systems I work on has a feature that lets you add new functionality via loading shared libraries (i.e., plugins). This is a pretty conventional technique for programs like Apache, IE, etc. but we add a new wrinkle; there are multiple programs that all need to load the same shared object. For instance, if you want to add a new protocol decoder, you're actually adding it in three places:

So, at some level here you actually have three plugins that work together, one for each application. You could do this as three separate .sos, but that makes for a nasty management problem, especially as the number of applications goes up, and of course it makes code re-use difficult. So, ideally, you'd like to just have one .so.

Getting something like this to work properly requires a fair amount of attention to dependencies (I'm assuming you know how to make a .so using ld -shared.) The simplest problem is that the plugins need to invoke functions that are in the main program. For instance, in the management shell we need to call functions in the main program in order to register our new commands. Normally, functions that are linked into the main program aren't exported to dynamically loaded objects, so you need to use the --export-dynamic argument to ld when you link the main program.

A secondary problem with this kind of reference is that there may be functions that plugins depend upon that aren't called anywhere in the program itself. Plugins need to be able to know they can call a specific API. In order to make this work, you need to force all the API functions to be linked into the application program (so they can be re-exported to the plugins). Basically, you do this by creating a new source file that references the API functions via placing a function pointer for the API function into some static variable. On UNIX-type systems, files are linked in one at a time, and the transitive closure of all references needs to be linked in. So, what you do is create some API forcing file which points to each API file (at least transitively) and then have that file export some variable that gets referenced in some source file that is actually used in the main program.

The above two techniques take care of making the functions we need available. Now we have to deal with the opposite problem, which is having things work when not everything is available. So, for instance, if we're writing an SSL processing module, it needs to reference OpenSSL in order to do its thing. But, the prettyprinter for its stats doesn't need OpenSSL. We don't want to force the stats system to link with OpenSSL just to print some values.

This is taken care of with two techniques. First, when we dynamically load modules, we call dlopen with the argument RTLD_LAZY. This tells it only to try to resolve functions when they're first referenced rather then when the library is loaded. This gets us part but not all of the way there. The second thing is that we need to compile our plugins with position-independent code---code which can run correctly no matter where the library is loaded into memory. With gcc, this is done with the -fPIC falg.

This is a simple fact and something I knew about, but when I started writing shared libraries for this system, I hadn't written one in a long time and I forgot -fPIC and yet all my shared libraries seemed to load and work properly so I never noticed the problem. Then I noticed that I was starting to have problems where even though I was loading with RTLD_LAZY, dlopen was still trying to resolve all the symbols referenced in the .so. This isn't just a code size issue: remember that the module needs to call functions in all the application programs, but the management shell doesn't provide the functions that are in the packet processing stack, so you get linkage errors. A little debugging resolved what appears to be the problem: if you don't provide -fPIC you get relocatable code and the linker automatically relocates it, but it tries to resolve all (or at least some) of the symbols even if they're not referenced, which, as I mentioned before, is bad.

So, to recap:

Fun, eh?

Posted by ekr at 8:43 PM | Comments (1)

June 9, 2006

FCC wiretapping regs upheld, so what?

The D.C. Court of Appeals has upheld the FCC's decision that "facilities-based broadband Internet access and interconnected VoIP services" need to provide CALEA access (see previous post here):
In a split decision, two of three judges on the panel concluded that the 2005 Federal Communications Commission requirement was a "reasonable policy choice" even though information services are exempted from the government's wiretapping authority.

The FCC has set a May 14, 2007, deadline for compliance, and the ruling drew praise from the FCC and the Justice Department, which sought the access.

"Today's decision will ensure that technology does not impede the capabilities of law enforcement to provide for the safety and security of our nation," the department said in a statement.

But the chief author of the 1994 wiretapping law, U.S. Sen. Patrick Leahy, criticized the court's decision, saying Congress had deliberately excluded the Internet when it wrote the wiretap law.

"The court's expansion of (the wiretapping law) to cover the Internet is troubling, and it is not what Congress intended," Leahy, a Vermont Democrat, said in a statement.

I'm not sure whether the FCC exceeded its authority or not, but I'm not sure it really matters one way or the other. First, the Bush Administration seems pretty aggressive about wiretapping without bothering to go through the standard legal channels. Second, the responses to revelations about Administration wiretapping suggest that it wouldn't be that hard for wiretapping proponents to revise the law to require CALEA access to this kind of system anyway.

Posted by ekr at 9:26 PM | Comments (2)

June 8, 2006

More on LinkedIn

Oh, one more thing: last time I logged into LinkedIn to accept one of these things it insisted that I was accepting their new user agreement and privacy policy, which basically say:
  1. You can't use LinkedIn for anything (you agree not to use it for communications which are "unlawful, libelous, abusive, obscene, discriminatory, or otherwise objectionable", which pretty much covers the space.)
  2. We can terminate your account at any time for any reason.
  3. You indemnify LinkedIn for any kind of damage resulting to anyone form your use of LinkedIn.
  4. We currently protect your privacy but in the future we might decide not to.
  5. "Any sensitive information that you provide will be secured with all industry standard protocols and technology". I guess this one means that they'll use SSL, IPsec, SSH, and S/MIME all together.

I guess if I actually used LinkedIn, I might want to export my data every so often so I couldn't be held hostage whenver they decided to change their policies. The link you want for that is here.

Posted by ekr at 9:25 AM | Comments (1)

LinkedIn Ettiquette

Periodically, one of my friends discovers LinkedIn and then the conventional thing seems to be to invite everyone you know, like this:
Lisa Dusseault has invited you to become a connection. Lisa will also become your connection.

Invitation date: April 11, 2006

Lisa's note:

I found you while I was searching my network at LinkedIn. Let's connect directly, so we can help each other with referrals. If we connect, both of our networks will grow. To add me as your connection, just follow the link below.

- Lisa

Anyway, I don't really use LinkedIn for my own contacts, but somehow it feels rude to just ignore these messages or (horrors!) reject them. So, despite myself I've ended up with a fairly extensive contact list. What now?

Posted by ekr at 9:13 AM | Comments (2)

June 6, 2006

On the morality of not working on life extension

Reporting (rather dismissively) from the Human Enhancement Technologies and Human Rights conference, William Saletan writes:
De Grey, the guy with the beard, called for higher taxes and research funding to "end the slaughter" of human aging. He argued, incoherently, that our failure to do everything possible to stop aging this instant was tantamount to mass murder.

Maybe Saletan is saying that De Grey's argument is presented incoherently, but I suspect he's saying that the whole argument is incoherent, which I'm not sure I agree with. The basic argument here, that failure to do something that would prevent people suffering or death is morally equivalent to causing that suffering or death, though not particularly widely respected, has a respectable pedigree. Indeed, if you replace aging with world poverty in Saletan's statement above, you get pretty close to Peter Singer's famous argument about famine relief.

Saletan doesn't deign to argue against De Grey, he just calls him incoherent, but it seems to me that there are three basic arguments against what Saletan reports Grey to be saying:

I certainly wouldn't put the point anywhere as strongly as Saletan suggests De Grey did, but I don't think that De Grey's position is incoherent either. Certainly, if life extension can be made to work, it seems like there are pretty strong moral arguments to be made for investing in it, just as there are strong moral arguments for investing in curing any other life threatening medical condition.

Posted by ekr at 10:14 PM

June 5, 2006

Followup on Tysabri

The FDA has followed up on its committee's recommendation and decided to allow Tysabri to return to market. For those who just tuned in, Tysabri appears to be an unusually effective MS drug with a rare but nasty side effect--risk of death from a brain infection called PML. This seems like a good thing, but as I argued earlier, it would have been even better to have let people make their own decisions rather than have the FDA make some global cost/benefit decision.

Posted by ekr at 11:19 AM

June 4, 2006

How to write a better extortion virus

BBC reports that the Archiveus extortion virus has been cracked. The way that Archiveus works is that it infects your computer and then encrypts your files. In order to get the encryption key (password, whatever) you are instructed to go buy drugs from a particular web site to get the decryption password. Anyway, it turns out that the virus uses a static key for everyone and someone has recovered that key. 1.

One way to think of an extortion virus is as a particularly pernicious form of involuntary DRM. As with standard DRM systems, you want to design such a system so that it doesn't have catastrophic failure modes where compromise of a single instance leads to compromise of the entire system. Having a single symmetric key that does all the encryption is clearly a loser as far as this is concerned, as we saw with CSS. Even better, we'd prefer that reverse engineering the virus didn't buy you anything. On the other hand, you'd really like all of the virus copies to be the same.

Luckily, modern cryptography comes to the rescue in the form of public key cryptography. What you do is generate a public key pair and embed the public key (Kpub) in the virus. The virus author keeps the private key (Kpriv). When the virus goes to encrypt your files, it generates a random symmetric key (Ksym) and encrypts the files under Ksym. It encrypts the Ksym under Kpub (E(Kpub,Ksym)) and stores the result on the disk somewhere and then erases Ksym.2 At this point, the only person who can recover Ksym (and hence your files is the person who has Kpriv). No amount of analysis of the binary can recover Kpriv because the virus doesn't know it, and if it's written correctly, Ksym is long gone.

Of course, this design has one downside: because Ksym is different for each victim, you somehow need to get ahold of E(Kpub,Ksym) in order to recover Ksym. Given this particular method of recovering the money, the obvious approach is to require the user to cut-and-paste the value into some field in the order form, which kind of screws up plausible deniability for the vendor who's collecting the money, assuming they had any in the first place. An alternative approach is to have the virus send a copy of E(Kpub,Ksym) to the virus author along with your e-mail address. Then, when you order the drugs they look up your e-mail address and send you Ksym. Of course, if you're going to do things this way, then you don't really need public key at all: just send Ksym in the clear and assume (almost certainly rightly) that the victim isn't running a traffic recorder on their network and so won't capture it.

1. Come to think of it, it's not clear why this took analysis. If it gives the same password to everyone, surely this is something you could detect without any kind of reverse engineering.
2. When I first heard about extortion viruses a few years back from Paul Kocher, this was the technique he described.

Posted by ekr at 12:58 PM | Comments (1)

June 2, 2006

Initial impressions on ISP data retention

The DoJ is starting to press ISPs to "keep records on the Web-surfing activities of their customers" [*].
The director of the Federal Bureau of Investigation, Robert S. Mueller III, and Attorney General Alberto R. Gonzales held a meeting in Washington last Friday where they offered a general proposal on record-keeping to a group of senior executives from Internet companies, said Brian Roehrkasse, a spokesman for the department. The meeting included representatives from America Online, Microsoft, Google, Verizon and Comcast.

...

While initial proposals were vague, executives from companies that attended the meeting said they gathered that the department was interested in records that would allow them to identify which individuals visited certain Web sites and possibly conducted searches using certain terms.

It also wants the Internet companies to retain records about whom their users exchange e-mail with, but not the contents of e-mail messages, the executives said. The executives spoke on the condition that they not be identified because they did not want to offend the Justice Department.

A few initial thoughts:

It would be nice to have some more details about what the feds are really going to insist on. So far, I've just seen this kind of vague summary.

Posted by ekr at 9:56 PM | Comments (1)