|
|||||||||||
 | Deployment | ||||||||||
|
It should be noted that the Applet signing requirements are only for those cases were there is a third party encryption device (such as CodeMeter and WibuKey/Securikey) that relies on the browser making a hardware access to the operating system. If the classes in Blackbird written for using them are not included in the overall applet, then the applet itself needs not reach beyond the sandbox and would not need to be signed. Blackbird is a Java Applet and is quite easy to deploy. Naturally what is needed is a server-side folder to store the Jar files. There are some steps however to signing the applet that should be taken beforehand. To better understand what that is all about, first refer to the documentation on this subject. A healthy knowledge of keytool is also good to have. For better security, you should always sign your own applet, and export the certificate to your end users. A typical signing session will start with the creation of the key pair, using this command: Now comes the export, a certificate to use to sign the jar files. What this next command does is "export" from your key store a certificate that will be used to sign your applet's jar files. To import this into your Keystore, a similar command is used on the client end:
The information output is this: Naturally the information is similar to the import - this is where the difference is! Contact the sender and compare the figerprints you see to the fingerprints they see. Of course if the transfer is "face to face", you can print out this information and hand if off with the certificate. It's not absolutely required that you import the certificate this way. A browser, when loading a signed applet, will display a permission screen asking if you want to trust the applet or not.  This is standard. Given the desire to use Blackbird may be centered around security, or you are using an applet class that you did not compile yourself but you know is good, yet still want to sign yourself, these steps should be considered. Now how to get down to actually signing the applet? Simple. However, before getting to that, it should be pointed out that Blackbird as is delivered has three Jar files, and this will grow. The third party encryption systems, using API hooks into runtimes, usually have their own Jar files that must be included in the classpath of Blackbird.jar (which will be spelled differently, as you will see). So what gives, then? If you use CodeMeter, WibuKey/Securikey, and any other system that uses a runtime or hardware for which an API is provided, chances are there is a .jar file that must not only be available to the applet on server side, but also signed. Blackbird is designed so that adding or removing additional encryption systems only takes minor modifications of the main applet (Blackbird.java) and removal of the entire .java source file for the encryption itself. Blackbird comes with all the available systems but you can easily remove them, and doing so, does not require addition of those jar files. So assuming that, at the inception of Blackbird having CodeMeter and WibuKey included, the means to sign the jar files is such: Notice that the signed version of these jar files starts with "S"? These are the files that go to the codebase on the server. Deployment ModesAt this point, the three jar files can be copied to the server, and the <applet> tag put into a web page to make use of the applet. Blackbird uses invoked anonymous JavaScript, meaning that you should use "MAYSCRIPT" in the applet tag, even though you are not adding any JavaScript into the web page! So to use Blackbird, all you need is this entry in the web page (preferably in the <HEAD>).The Applet has several "Deployment Modes" available, and this may expand in ability as time goes on. Setting the applet Deployment Mode is also done in the Applet Tags, with two parameters that tell the applet what mode it is to run in when it is initialised. Here are the deployment modes:
Note: These PARAM tags show the CodeMeter and WibuKey jar files included in the archives. If these Encryption Entities are removed from the applet (you can comment them out of the source code and recompile the applet), then those .JAR files will not be needed. Deployment Mode 0 - Default Mode To use Mode 0 Blackbird, all you need is this in a web page, but you can omit the PARAM tags in mode 0: Deployment Mode 1 - IFRAME DOM Accessor Mode To use Mode 1 Blackbird, use two PARAMeters as seen below. First is the mode parameter that the applet will look for, and the target parameter tells the applet which "nth" IFRAME to access. In this example it shows 0 for a value, and this could be the case if you have only one IFRAME or if you are accessing the first inline frame. This APPLET entry would be on the same page as the IFRAME (not on the page being "sourced" into the IFRAME). Below is an IFRAME entry that would be on the same DOM level as the applet, but the applet is going to "reach into" the DOM inside that IFRAME and affect the encrypted entries there. (Note: security restrictions limit this to the same URL/website only). Now it might be construed that an html page with the APPLET tags sourcing that IFRAME with the encrypted entries might suffice. This might not be enough. If the reason for using Mode 1 was for using the applet in a web forum without modifying the forum pages due to restrictions or speed, you would have to switch those forums over to accepting HTML in the posts. This can get a forum hacked so newer forum packages do not allow that by default. Try asking around the internet about how to switch over to allowing HTML and experienced Administrators will first tell you it's a bad idea. Therefore if you are using Mode 1 Blackbird for a web forum or blog that does not allow posting of HTML tags, then you have to (or the Administrator has to) program custom BB Code to accept the BB code that the applet is capable of generating and convert that to HTML that the applet needs. This is not as complicated as it seems, and much of this depends on the forum software in use. Blackbird assumes newer standards of BB Code but if you find this lacking in any way or there are other "standards" of special codes out there that Blackbird should have, please inform us of that so it can be added. Each if the Encryption Entities now has an expandable code generation system that allows easier additions of code output standards. It should also be assumed that this is NOT restricted to Mode 1 deployment only, but gets first mention here as forums that use BB Code were the reason for Mode 1. To program your web forum for converting the BB Code Blackbird Entries into HTML, you need to define in the ACP (Administrator Control Panel) what the BB Code looks like and then what the HTML output code from the server will look like. To further detail this, look at this picture of the entry for CodeMeter encryption. All others are much like this, but their parameters differ. All of them will be explained.  Evident here is how you have to specify what the BB Code is, and then what the HTML Code will be. Though these examples are for phpBB, differences should be expected (especially) with older systems. What follows here are the entries needed for each Encryption Entity:
Another thing that differs in Mode 1 Deployment is failure to trigger decryption on page load, as seen in Mode 0. Usually those Encryption Entities needed a Identification of Initialization vector will not attempt a decryption but WibuKey and Rot13 should be automatic. In Mode 1 this does not happen because for those Encryption Entities not needing additional data to trigger a decrypt call, the page with encrypted data is loaded when the applet is already loaded, and the decryption loop is not called upon again. There in Mode 1 a new Menu Item appears at the top.  This is simply for triggering the main decryption loop, and will appear in those cases where Mode 1 is in use. If the information needed by those Encryption Entities that require initialization vectors, passwords, and identifiers are not provided already, then the applet will skip over them. Of course the codebase in this example is "bbstore" - that changes depending on the file name you use when you load the signed applet onto the server. There is also some issue with "MAYSCRIPT" and whether or not it is needed. This applet tag was tested for IE, Firefox, and Safari on three platforms (WinX, MacX, and Linux) and the applet tag in this form worked in all tests. Also highly important is the name of the applet. The javaScript invoked from inside of the applet depends on the applet having that name in the DOM!!!! If you change it in the tag, you will have to change it in the "getJavaScript" function of each encryption class. Keep this in mind if you choose to change this name. You can choose to change things in the classes themselves, and there is some minor difference in the JavaScript sent by some of the classes (for test purposes). The width and height of the applet is due to the banner size, and not for any other need. But remember that if the end users are to have to make use of the applet's menu - which is invoked from right-clicking the applet itself - the applet must be visible. ROT13 may not need interaction and there may be some encryption classes (currently also the case with WibuKey) that does not require further interaction. So far this should suffice for applet-signing and deployment. Note that instructions for compiling the applet itself are not given here. Blackbird comes in the form of a Netbeans project file (apologies to those who use Eclipse but if you import the code to Eclipse and want to aid your Eclipse-using bretheren, Blackbird in Eclipse project form can be made available here). The Netbeans IDE was used for the entire development process of Blackbird. | |||||||||||