Apache Wookie W3C Widget Digital Signature Implementation - GSoC2012

I am here sharing my GSoC 2012 project details which I enjoyed a lot while learning. This includes a brief introduction on the project with it's design, implementation and guidance on using. The implementation has been done using Apache Santuario 1.5.2 release to generate digital signatures. The project is mentored by Scott Wilson who was so helpful and supported by the community. This is Scott Wilson's post on the project.

What is Apache Wookie?


Apache Wookie is a Java server application that allows widget uploading and deployment as useful for variety of applications. This may include gadgets to quizzes and games. Wookie has been based on W3C widget specification while providing flexibility on Google Wave gadgets etc. At the moment of writing, it is in the Apache incubator getting ready to graduate as an Apache Project. 

Objective of the project


The objective this project is to implement the 'W3C XML Digital Signatures for Widgets' specification in Wookie which has been reported as a new feature. This means automating the widget upload and deployment in a secured manner without  having an administrator to approve each widget. If a widget store or an author is trying to deploy a widget, Wookie needs to be capable of ensuring whether it's a trusted party and let deployment or avoid it as suitable.


Design


The best way to achieve this is letting the widgets' content be digitally signed and verifying the signatures at Wookie before deployment. In the way basic security needs of integrity and non-repudiation can be achieved according to W3C XML digital signature for widgets specification. So a new module has been introduced to Wookie as digsig-client to allow authors and distributors to sign the content of widgets. It provides a user friendly Java Swing UI to get the inputs from the signer. Then process them according to the W3C spec and package into a .wgt ready to be deployed in Wookie server. The client is developed according to Model View pattern separating the signing logic and UI having a coordinator among them.

Then the administrators are allowed to set up the security level of the server whether to reject the widgets that do not submit a valid signatures or to allow them under a warning. 

Implementation

Signing

The signature is generated according to the exact details specified in the spec as,
  • Signature algorithm - is RSA using the RSAwithSHA256
  • Key length - for RSA is 4096 bits.
  • Digest method - SHA-256.
  • Canonicalization algorithm - Canonical XML Version 1.1 (omits comments) 
  • Certificate format - X.509 version 3

Implementation has been done using Apache Santuario 1.5.2 release. To achieve the highest possible security, the public key certificate of trusted signers needs to be imported to the trusted keystore of Wookie. You can access the code at current SVN of Apache Wookie which can be used to generate a detached signatures on any other content too. 

Verification

Wookie supports 2 methods of widget deployment that,
  • Drop .wgt into /deploy
  • POST with attachment to /wookie/widgets 
Widgets sent-in both ways are verified  in the same manner starting from W3CWidgetFactory class. It bends the flow through DigitalSignatureProcessor class if the signature verification is turned on in widgetserver.properties file. The processor identifies the signature files inside the widget and try to verify each extracting the relevant public key certificate from Wookie trusted store. According to the settings at widgetserver.properties, it decides whether to reject widget or deploy with a warning in case of a invalid widget found.



In the processor it, 

  • Check for presence of signature file,
  • Categorize them as author or distributor to understand the which content should be addressed in signature,
  • Check whether all content is signed according to the W3C widget digsig spec.
  • Retrieve trusted public key certificate from Wookie trussted keystore
  • Throws exceptions or put warnings when invalid signatures are encountered
  • handle widget deployment accordingly

You can access the code at current SVN of Apache Wookie.

Usage


When the digsig-client is run it will show up a Swing UI as follows.
  • Have to select the role of the signer whether author or distributor
  • Then should point to the keystore which stores the relevant private key
  • It's password should also be given followed by private key alias
  • Then if private key password is same as the keystore password and certificate alias is same as private key alias you can leave it blank.
  • Then once you select the widget folder from the file chooser, digsig-client will show the files selected to be signed from the widget according the role. This will automatically skip files starting with '.' and signature files as mentioned in the W3C spec.
  • Then you can give the name of widget 
  • Once signed the <name>.wgt file is stored in the widget path including signed content and generated signature file, being ready to send to deployment as follows. 



In Wookie Server side, administrators need to set the following properties according the security requirement of their context. This is located at widgetserver,properties file.
# digital signature settings
# Set this property to have Wookie check widget digital signatures when
# deploying a widget
widget.deployment.verifysignature=true
#
# Set this property to determine how Wookie treats widgets with invalid
# digital signatures.
#
# If set to true, Wookie will not deploy any widgets with invalid
# digital signatures. If set to false, the widget will be imported
# and a warning logged.
widget.deployment.rejectinvalidsignatures=true
#
# If set to true, Wookie will only deploy Widgets that have valid digital signatures
# AND that each signature uses a trusted certificate located in the trusted keystore,
# disregarding setting the above to false.
widget.deployment.rejectuntrustedsignatures=false
#
# Name of the trusted keystore file
widget.deployment.trustedkeystore=wookieKeystore.jks
#Password for the trusted keystore file
widget.deployment.trustedkeystore.password = wookie
After that Wookie server will handle the deployment of widgets in a secured manner given that the trusted public certificates are imported into the trusted keystore of the Wookie server. 
 
Following is a sample author signature generated by digsig-client. 
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="AuthorSignature">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2006/12/xml-c14n11"></ds:CanonicalizationMethod>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"></ds:SignatureMethod>
<ds:Reference URI="build.xml">
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod>
<ds:DigestValue>NWR/9AmarWLIAOFg6XHWF0Myf3MrSk+G13ioHAGHm00=</ds:DigestValue>
</ds:Reference>
<ds:Reference URI="config.xml">
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod>
<ds:DigestValue>KhOSsl7spZ1v8ugGLy2+Pzl/Iinyv9Qwsqll60L16sw=</ds:DigestValue>
</ds:Reference>
.
.
.
<ds:Reference URI="images/background.jpg">
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod>
<ds:DigestValue>S02OAXynBMEK+Br9HWGaKbljDjW2I9MPAHegWePA5Gw=</ds:DigestValue>
</ds:Reference>
<ds:Reference URI="#prop">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"></ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod>
<ds:DigestValue>rCbva4a0iK6CmjtYZck/3bdatRegvNe2zGi3kLDd6Yk=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
a7FxoERD3leteDx+jJ7xwXL8iUNC/0x6mOoS9rLOCrP0kh4tULk6zKr9XLbnv1LAVfwdJKXaVG1z
IrRt3+XLspvEONIqPt8z9uZ/J9ff+/U5srt6trSbBRY/JeGGqKE5kz/0Dc3YFQzQtoWwdBR4KuMG
Ghhi5X3iXDJmpgKv+C8=
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIICSTCCAbKgAwIBAgIET78PqzANBgkqhkiG9w0BAQUFADBpMQswCQYDVQQGEwJMSzEQMA4GA1UE.................pprfWjkszI21SecAXUPiDE3yxIaEOOBOZ4EhUayH5+bE/widid76ibazpqrLzvi5V3zglTkiqrLeKN8Hdu1baRLOw==
</ds:X509Certificate>
</ds:X509Data>
<ds:KeyValue>
<ds:RSAKeyValue>
<ds:Modulus>
3JwTnPNV7ZXjT4o4oKuw9OSJXxID++i5UDuceV0GKNB4pprfWjkszI21SecAXUPiDE3yxIaEOOBO
Z4EhUayH5+6PVaNHo5qRZbpkL10zDCzr2efxp/3QbSnFFItn9EnRFAGvEBFdF9fOuiLNt0p2vDDm
d+GLqGKv7sslRK5FcB8=
</ds:Modulus>
<ds:Exponent>AQAB</ds:Exponent>
</ds:RSAKeyValue>
</ds:KeyValue>
</ds:KeyInfo>
<ds:Object Id="prop">
<ds:SignatureProperties xmlns:dsp="http://www.w3.org/2009/xmldsig-properties">
<ds:SignatureProperty Id="profile" Target="#AuthorSignature"><dsp:Profile URI="http://www.w3.org/ns/widgets-digsig#profile"></dsp:Profile></ds:SignatureProperty>
<ds:SignatureProperty Id="role" Target="#AuthorSignature"><dsp:Role URI="http://www.w3.org/ns/widgets-digsig#role-author"></dsp:Role></ds:SignatureProperty>
<ds:SignatureProperty Id="identifier" Target="#AuthorSignature"><dsp:Identifier>test</dsp:Identifier></ds:SignatureProperty>
</ds:SignatureProperties>
</ds:Object>
</ds:Signature>

The relevant steps for generating key pairs needed for digital signatures and procedure to import public certificates can be found in this post.
Enjoy with Wookie...............!

Popular posts from this blog

Signing SOAP Messages - Generation of Enveloped XML Signatures

Image
Digital signing is a widely used mechanism to make digital contents authentic. By producing a digital signature for some content, we can let another party capable of validating that content. It can provide a guarantee that, is not altered after we signed it, with this validation. With this sample I am to share how to generate the a signature for SOAP envelope. But of course this is valid for any other content signing as well. Here, I will sign The SOAP envelope itself An attachment  Place the signature inside SOAP header  With the placement of signature inside the SOAP header which is also signed by the signature, this becomes a demonstration of enveloped signature. I am using Apache Santuario library for signing. Following is the code segment I used. I have shared the complete sample here to to be downloaded . public static void main(String unused[]) throws Exception {         String keystoreType = "JKS";         String keystoreFile = "src/main/resour
Read more

How to convert WSDL to Java

Image
Background Basically WSDL (Web Services Development Language) is an XML document used to describe or locate web services. WSDL stands for Web Services Description Language. The document describes a Web service. It specifies the location of the service and the operations that can be taken.  WSDL2Java is distributed with Axis2 package of Apache and need to set-up Axis2 to use this service. A  guide to set-up Axis2  can be found in apache organization documents .WSDL 2.0 is the currently using version. Obviously JDK should be properly installed too. Note: For the 3rd method you are not needed to set these things by yourself. The WSDL document includes server Java programs for Web services and generated classes using WSDL2Java feature includes client stubs, server skeletons and data types that can help in writing client side. The generated stub classes play a great role in distributed computing and if you are interested can read on  what are stub classes . In brief talking, 
Read more

Tomcat JDBC Pool - Connection Leak - Catch the Culprit

Database connection leaks are something that can stay hidden unless paid specific attention and would come to the surface at the most critical stages at a peak time of the system. We would manually check if all the open connections have been closed properly. Then we have various code quality plugins that would scan and check for that. Still when the connections are passed through a complex structure of program both of these can miss a possible connection leak. Then at unit test or integration test levels, we can have checks to validate the counts in the connection pool to avoid this unfortunate situation, that would keep engineers busy at year-end, black Friday, etc. :) In the unfortunate case of hitting with a performance degrade or a total crash of the system which can be propagated via a JDBC connection leak, when we suspect a connection leak, how easily and quickly isolate the culprit. In the Tomcat connection pool, we can do this using 3 properties. removeAbandoned If a
Read more