[foaf-protocols] some ssl + HTTP security-related design issues specific to webid protocol

peter williams home_pw at msn.com
Sat Dec 25 18:09:51 CET 2010

In webid protocol design, one might play with some ideas first used in the
SET protocol (building on a VISA idea, that applied some IBM countermeasures
against adaptive ciphertext-only vulnerabilities of the RSA cipher when used
for key transport in commodity systems).


"Plaintext-awareness" is the basis of one definition of "semantic security"
for authentication exchanges that rely on encryption. It also has
implications concerning the strength of crypto primitive composition against
adaptive ciphertext-only (mis-)uses of the RSA cipher, in particular


OAEP <http://en.wikipedia.org/wiki/Optimal_Asymmetric_Encryption_Padding>
was the grand-daddy of this topic area, but it's the _application_ that VISA
made that we might  learn from. We might be able to apply the design
principles the Set team used in designing application-specific crypto
primities to the webid protocol.


OAEP concerns the formatting of the plaintextblock given to the RSA cipher,
when doing entity authentication using the  (complete!) SSL handshake.
Imagine a straw cut into 2 non-equal lengths, with an arrow head in the end
of each pointing one at the other. Each is a one-way function, but with
limited collision-resistance. By playing with xor masking (one time pads)
and by hash-key derivations functions generators, one side generates masks
for the other, where the PAN (visa card number) acts as something "ONE MUST
HAVE KNOWN" as a sender for the unmasking process to work (assuming the
recipient has already done RSA ciphertext deciphering). The PAN "something
you know" conceptually wraps a random seed that drives the reversible
process. If you don't know (or "claim") the PAN as sender, the attacker
cannot create an unwrappable plaintext within the window of attack, as
protected by the strength of RSA and the RSA keying material (hours..) and a
short expiry window (minutes) for the messages exchanged in the SSL
handshake protocol.


In short, you have a ciphered codebook, vs. merely a cipher.


Now, one can do the same kind of thing with webid protocols, replacing other
values for the "claim value" played visa card PAN.


Should the FOAF PPD/document contain a field (perhaps current time, to the
microsecond) modified before starting the webid protocol run, the webid
protocol might use a variant of some of the SSL handshake messages that
applies OAEP to the key transfer phase of the SSL handshake protocol, where
the time derives the plaintext-awareness property. The idea is that the
recipient has to pull the FOAF document cited at the URI in the client cert
to learn this "claimed" value, before it can complete the webid protocol
run. The crypto ensures this. If the client cert is release only in a
handshake protected by a current SSL session (which I advise.), the first
handshake does not use client auth.


There  are obviously many variants to these ideas, when used to implement
"orgcon" policies. When imposing originator controls, perhaps one seeks to
address threats of cache poisoning of one's foaf documents. The claimed
value in the latest FOAF document not be a time nonce, but might leverage
hash chain computations that tie the version of the document release to the
webid server to its previous versions - i.e. cached copies stored in the
global web cache or torrent cache. This can provide forensic evidence of
interference with caches, determining at what point the interference


In my experiments, I've been using the Opera browser that cooperate with the
Opera cloud provider while Im online. In this context where the cloud vendor
is my servant rather than I'm its subscriber , the supporting cloud has to
pull the foaf card from my PC file server each time it served, since the
public http endpoint for the card is purely virtual pointer to the tunnel
between my browser and the cloud. Thus, I can change the physical foaf
document before I commence using the webid protocol. In a better automated
implementation, the streaming protocol between browser and cloud might do
this for me.


From: peter williams [mailto:home_pw at msn.com] 
Sent: Thursday, December 23, 2010 11:23 AM
To: 'foaf-protocols at lists.foaf-project.org'
Subject: RE: [foaf-protocols] some ssl + HTTP security-related design issues
specific to webid protocol



Ideally, any such fiddles should of the SSL handshake protocol (leveraging
such as OAEP-capable ciphersuites that add plaintext-awareness to RSA) while
accommodating the unique nature of the webid protocol and its
"scheme-centric" semweb context.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20101225/90c009fa/attachment.htm 

More information about the foaf-protocols mailing list