New Architecture and Design for Mozilla Firefox Mozilla Firefox has enabled multi-process operations and phased out the add-on technology...
New Architecture and Design for Mozilla Firefox Mozilla Firefox has enabled multi-process operations and phased out the add-on technology. Mozilla recommends adopting the new web extension and native messaging for the replacement of the addon technology. The first drafting of the architecture is to connect the new web extension and native messaging to the NSS library. However, there are user certificates which released in the production with the issues of missing ‘Netscape Cert Type’ field. These user certificates are having difficulties in calling the NSS libraries for signing function. In contrast, the same user certificates function well with a nonMozilla web browser, i.e. Internet Explorer and Google Chrome which opted for CryptoAPI and CSP libraries. The reason being is, the field of ‘Netscape Cert Type’ is not a sensitive field to CryptoAPI library. With the prementioned factors, the decision is to revamp the design of digital signature solution from add-on technology to extension and native messaging technology. It involved the decision to drop the NSS dan PKCS#11 libraries and to replace with the CryptoAPI and CSP libraries. Thus, in order to support Firefox 58 onwards, the new architecture is as shown in Figure 7. < Firefox 57 >
Firefox 58 Add-on Extension and Native Messaging NSS CryptoAPI PKCS#11 CSP Device Drivers Figure 7: New Web Extension Architecture for Mozilla Firefox 5. Digital Signature Ecosystem With web extension technologies are built in silos, the integration of web application to the digital signature as a service demands for simplicity. The first problem is the digital signature operation on multiple web extensions technologies generates an unstructured format of data and digital signature. The integration requires a web application to provide functionalities to receive unstructured data from multiple web browsers and to format the unstructured data to a structured data that is independent on the type of web browser. The web application may be a third-party software vendor who requires to provide a digital signature as a service.
However, requesting for the third-party software vendor to manage the integration code may impede the delivery of the digital signature solution. The second problem is inevitable code changes in web extension, forces code changes in the web application that provides the digital signature as a service. For example, if there is a new request to support time stamping features and leads to the upgrade of the web extension version, the web application requires to add the new time stamping parameter, manage the time stamping data and supports the latest web extension version. The code changes occur in multiple places due to the support of multiple web browsers. If multiple software vendors adopt the digital signature solution, the codes changes must reflect on all code of software vendors immediately. The third problem is the chaos of web extension installation in the client machine. Each of the web extension has its installation policy. Each of the web International Journal of Intelligent Computing Research (IJICR), Volume 10, Issue 3, September 2019 Copyright © 2019, Infonomics Society 1019 extension has its installation files; C++ and JavaScript. For web security purposes, the web extension should be selected from the web browser extension store and manually install by users. In a recent development, Google Chrome browser version 73 introduces a new group policy that enables an administrator of an organisation to configure and control instances of Google Chrome Browser [16]. This policy results in a seamless installation of the browser extension, where it is configured to automate the installation of browser extension to the user. However, it seems to be unethical to install a web extension without user’s permission. In solving the prementioned issues, a general JavaScript called ‘Web Signature Script’ lays in between the web browser and web extension layers as illustrated in Figure 8 is created. The purpose is to simplify the digital signature integration. The script is responsible for structuring data and the signature in JSON format. The JSON format provides the content secured messages with information of algorithm and digital signatures. The JSON format acts as a container to present the data to sign and the digital signature and built-in JavaScript language. The JSON format contains four important fields. The first field is the payload which describes as the value of the original message to be signed. The second field is the protected which contains the algorithm used to generate the signature. The supported signing algorithms are RSA with hash algorithm SHA256, and ECDSA with hash algorithm SHA256. The protected fields contain the expiry of the data and the signature timestamp. The third field is the header which contains user certificate signing and the certificate chain. The last field is the signature which contain the signature of the digital signing. All information is in Base64 format.
Despite multiple selection of web browsers, the web application will receive the JSON signature data format upon user successfully perform digital signing. The script manages the data format of each specific web extension for each of the web browser. Any additional of new features which requires new parameter will be added in the script. The script provides an abstraction API for the integration of third-party software vendor to perform digital signing and verifying digital signatures based on the JSON format. The API provides uniform signing and verification functions for all platforms and browsers. The third-party software vendors will only require including the web signature script in the web application as JavaScript and perform either signing or verification of signature with additional two lines of codes. In case of a new updated version for the web extension, the only requirement for the web application developers is to replace the web signature script with the latest version. Thus, the script should offer minimal changes or effort for web application developers.
For the digital signature solution, to support the installation of web extensions in multiple web browser, a standalone installer is created. The installer is set to cater to the automatic installation process, supports for manual installation of the web extensions from the browser store and requires a user manual agreement to set required security policy prior for installation. In summary, the digital signature ecosystem is built based on client and server technology. The client is a cross-platform web browser extension and a minified Web Signature Script, which performs signing of data, generates and verify the digital signature on the web browser. In the future, the extension and the native messaging framework will be implemented for all web browser as in Figure 8. The cryptographic libraries will be CryptoAPI and CSP. The server is a Java library, which performs online verification of the digital signature and the certificate.
No comments