Security

Function

Security is critical for the success of PageBoxes because:
1. Constellation are cross-organization infrastructures. A participant must be able to trust other participants.
2. Presentations are deployed on a large number of PageBoxes. In case of error the PageBox host must be able to identify and notify the publisher. The publisher must be able to diagnose errors occurred on a deployed presentation.
3. PageBox infrastructure should provide a charging service.

1. Architecture

   

   The PageBox architecture involves six actors:

   1. The repository that deploys presentations
   2. The publisher who publishes presentations
   3. The administrator who administrates repositories
   4. The subscriber who subscribes PageBoxes
   5. The PageBox that hosts presentations
   6. The customer who uses presentations

   The infrastructure is not centralized. It can include many repositories and PageBoxes don't require their availability. However a repository acts as a hub for a given presentation.

2. Charging service

   We found some inspiration in a Publishing and Royalty Model for Networked Documents. This document was written by Ted Nelson for the Xanadu project, the ancestor of the Web and considers the publication of documents.

   It describes three main roles:

   1. The document publisher, responsible for any disagreeable consequence under law and tort
   2. The service provider who agrees to send the document to the customer
   3. The customer who agrees to pay the document at a rate specified by the publisher and a delivery fee to the service provider

   In case of PageBox infrastructure, the same rule can apply with four roles:

   1. The presentation publisher, responsible for any disagreeable consequence under law and tort
   2. The repository, responsible for the deployment of the presentation on PageBox hosts
   3. The PageBox host, who agrees to run the presentation
   4. The customer who conceptually agrees to pay for the presentation

   The case is more complex because different actors can receive the payment. We consider here three common scenarios:

   1. The shopping basket presentation

      

      The presentation bills the customer and get the money. The presentation publisher pays the provider(s), the PageBox hosts and the repositories.

      The provider typically:

      • Maintains the inventory and provides availability web services
      • Is responsible for the good delivery
      • Charges the presentation publisher

   2. The tributary presentation

      

      The provider bills the customer and get the money. It pays the presentation publisher. The presentation publisher pays the PageBox hosts and the repositories.

   3. The advertised presentation

      

      The advertiser pays the presentation publisher. The presentation publisher pays the PageBox hosts and the repositories.

The rule is:

1. The repositories and PageBox hosts charge the publisher. The publisher, the repositories and the PageBost host must be identified.
2. The publisher is paid by the customer, the provider or the advertiser. The mechanism is implemented by the presentation outside the scope of PageBox.

Design

1. Principle

   The repository (PublisherServer) uses HTTPS with public key authentication. The SSL/TLS handshaking is:

   1.	Client hello	----->
   2.		<-----	Server hello
   3.		<-----	Certificate
   4.		<-----	Certificate request
   5.		<-----	Server key exchange (Optional)
   6.		<-----	Server hello done
   7.	Certificate	----->
   8.	Client key exchange	----->
   9.	Certificate verify (Optional)	----->
   10.	Change cipher spec	----->
   11.	Finished	----->
   12.		<-----	Change cipher spec
   13.		<-----	Finished
   14.		<-----	Encrypted data

   The client can check the server certificate and the server can check the client certificate. Partners cannot repudiate their messages because only the certificate owner has the private key allowing to sign the request.

2. mod_ssl

   The handshaking above implies that the server requests the client certificate. This capability is described in Servlet specification but is not always implemented in application servers. Therefore in Publisher version 1.0.5, we use an Apache front-end server with mod_ssl:

   
   1. The publisher publishes a presentation with PublisherClient.
   2. The administrator uses a browser to administrate the repository.
   3. PageBoxes download the presentation.
   4. Apache checks the validity of the client certificate and forwards the requests to PublisherServer using the ajp13 protocol.
   5. PublisherServer retrieves the client certificate.
   PublisherServer doesn't require a front-end server. In secured mode, given an HttpServletRequest request, it requires:
   1. request.isSecure() to be true
   2. request.getScheme() to be https
   3. javax.servlet.request.X509Certificate attribute to be set

   A publisher or administrator should only use one certificate, whatever browser or application that she/he uses. It is difficult but not impossible to do so. We describe below a solution. It is possibly not the only one. We also didn't test all browser versions.

   1. We found Netscape 6.0 buggy.
   2. Opera 5.11 was very convenient for our tests as it allows setting the algorithms but it doesn't support exporting certificates.
   3. Netscape 4.5/4.7 and Internet Explorer 5/5.5 allow exporting certificates and private keys but Java 2 doesn't understand certificates exported by Internet Explorer

   Therefore use Netscape 4.77, which uses a 128 bits encryption, at least to require certificates. Next export the certificate in PKCS#12 format. Then you can import it in IE 5 and use it in Java. See the Mindprod site for more information.

3. Publisher registration

   A certificate is valid for Apache/mod_ssl if it was signed by an authority that the repository trusts.

   PublisherClient checks that the publisher has registered its certificate. The registration is implemented in a form where the publisher provides information such as her/his credit card number or address.

   Not implemented in version 1.0.5

   1. The repository defines how much it charges the publishers and pays the PageBox hosts. Criteria can be deployment cost, presentation size x time, number of presentation calls... It makes criterion available on HTML pages and XML files.
   2. When it subscribes, the PageBox host agrees on the fee.
   3. The publisher agrees on the fee when she/he publishes.
   4. PageBoxes report presentation use to the repository.