| all | frequencies |
|
exhibits | applications |
|---|---|---|---|---|
| manual |
| app s | submitted / available | |||||||
|---|---|---|---|---|---|---|---|---|
| 1 |
|
Users Manual | Users Manual | 364.53 KiB | ||||
| 1 | Cover Letter(s) | |||||||
| 1 | External Photos | |||||||
| 1 | ID Label/Location Info | |||||||
| 1 | Internal Photos | |||||||
| 1 | Test Report | |||||||
| 1 | Test Setup Photos |
| 1 | Users Manual | Users Manual | 364.53 KiB |
WebIdentity Developer Guide v5.0 1 Copyright 2007 Eutronsec Spa - Via Gandhi, 12 - 24048 Treviolo (BG) Italy. All rights reserved:
The trade names of the products mentioned herein are brand-names belonging to the rightful owners. The WebIdentityDL electronic key has proved compliant with the following regulations:
CEI EN 61000-4-2; CEI EN 61000-4-3; CEI EN 55022 as required by:
CEI EN 61000-6-1, CEI EN 61000-6-2, CEI EN 61000-6-3, CEI EN 61000-6-4 which set forth specific standards for the following tests:
ESD Immunity Test Immunity Test against radio-frequency broadcast EM fields Broadcast Emission Test In compliance with the Fundamental Requisites of European Directives EMC 89/336/CE and 2004/108/CE FCC ID: TFC-AAL EUTRONSEC S.p.A. WebIdentityDL Supply: 5V DC Absorption: 30 mA This device complies with Part 15 of the FCC Rules. Operation is subject to the following two conditions:
(1) this device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may cause undesired operation. NOTE: This equipment has been tested and found to comply with the limits for a Class B digital device, pursuant to Part 15 of the FCC Rules. These limits are designed to provide reasonable protection against harmful interference in a residential installation. This equipment generates, uses and can radiate radio frequency energy and, if not installed and used in accordance with the instructions, may cause harmful interference to radio communications. However, there is no guarantee that interference will not occur in a particular installation. If this equipment does cause harmful interference to radio or television reception, which can be determined by turning the equipment off and on, the user is encouraged to try to correct the interference by one or more of the following measures:
- Reorient or relocate the receiving antenna.
- Increase the separation between the equipment and receiver.
- Connect the equipment into an outlet on a circuit different from that to which the receiver is connected.
- Consult the dealer or an experienced radio/TV technician for help. Caution: changes or modifications not expressly approved by the party responsible for compliance could void the user's authority to operate the equipment. IMPORTANT REMARKS Due to the limited space on the product shell, all FCC certification references are on this technical manual. 2 3 Table of contents 2 1.9 3.1 3.2 3.3 1.8.1 1.8.2 1.8.3 1 PREFACE ................................................................................................................................................................. 7 ABOUT THIS MANUAL .......................................................................................................................................... 7 1.1 ENVIRONMENTS SUPPORTED BY VERSION 5.0 ...................................................................................................... 7 1.2 1.3 HOW TO USE THIS MANUAL.................................................................................................................................. 7 1.4 ................................................................................................................................................................................... 7 1.5 ................................................................................................................................................................................... 7 ASSUMPTIONS...................................................................................................................................................... 7 1.6 FONT CONVENTIONS ............................................................................................................................................ 7 1.7 1.8 INTERRELATED DOCUMENTS ............................................................................................................................... 8 Software components .................................................................................................................................. 8 Documentation............................................................................................................................................ 9 Distribution............................................................................................................................................... 10 FEEDBACK ......................................................................................................................................................... 10 INTRODUCTION .................................................................................................................................................. 11 2.1 WEBIDENTITYDL: THE NEW MODEL ................................................................................................................. 11 SECURE AUTHENTICATION IN WEB-BASED APPLICATIONS.................................................................................. 11 2.2 2.3 THE WEBIDENTITY SOLUTION ........................................................................................................................... 11 FIELDS OF APPLICATION..................................................................................................................................... 12 2.4 USB TOKENS..................................................................................................................................................... 12 2.5 AUTHENTICATION.............................................................................................................................................. 12 2.6 2.7 CRYPTOGRAPHY ................................................................................................................................................ 12 REMOTE CONTROL............................................................................................................................................. 13 2.8 3 REQUIREMENTS ................................................................................................................................................. 14 CLIENT .............................................................................................................................................................. 14 SERVER.............................................................................................................................................................. 14 COMPATIBILITY BETWEEN 5.0 AND 4.0 VERSIONS ............................................................................................. 15 INSTALLATION AND CONFIGURATION ...................................................................................................... 16 CLIENT .............................................................................................................................................................. 16 Example installation of a web page ....................................................................................................... 16 EXPLORER USERS IN POSSESSION OF A WEBIDENTITYDL DEVICE ............................................. 16 EXPLORER USERS IN POSSESSION OF A WEBIDENTITY3P DEVICE .............................................. 17 FIREFOX (or Mozilla and Netscape) USERS IN POSSESSION OF A WEBIDENTITYDL .................... 17 FIREFOX (or Mozilla and Netscape) USERS IN POSSESSION OF A WEBIDENTITY3P..................... 17 WINDOWS 98SE USERS IN POSSESSION OF A WEBIDENTITYDL DEVICE ..................................... 17 LINUX USERS .......................................................................................................................................... 17 MAC OS X USERS.................................................................................................................................... 17 AMINISTRATORS PERMITS FOR INSTALLATION .............................................................................. 18 SERVER.............................................................................................................................................................. 18 5 FEATURES............................................................................................................................................................. 19 5.1 INTEGRATED FEATURES ..................................................................................................................................... 19 5.2 WEBIDENTITY CONTENTS .................................................................................................................................. 20 Server Secret ............................................................................................................................................. 22 OPERATION........................................................................................................................................................ 23 AUTHENTICATION.............................................................................................................................................. 23 Esample log-in from a web page............................................................................................................ 25 FUNCTION...................................................................................................................................................................... 27 METHOD........................................................................................................................................................................ 27 DESCRIPTION................................................................................................................................................................. 27 COMPONENT.................................................................................................................................................................. 27 CHALLENGE GENERATION............................................................................................................................................. 27 INITRNDSESSIONSTRING .............................................................................................................................................. 27 GENERATION OF TIME-VARIABLE RANDOM SESSION STRING. ...................................................................................... 27 4.1.1 4.1.2 4.1.3 4.1.4 4.1.5 4.1.6 4.1.7 4.1.8 4.1.9 5.3 5.4 5.2.1 5.4.1 4.1 4.2 4 4 5.5.1 SERVER ......................................................................................................................................................................... 27 RESPONSE COMPUTATION ............................................................................................................................................. 27 READPIN........................................................................................................................................................................ 27 COMPUTATION OF RESPONSE BY USING THE WEBIDENTITY TOKEN ............................................................................... 27 CLIENT .......................................................................................................................................................................... 27 RESPONSE VERIFICATION .............................................................................................................................................. 27 DECRYPTPIN .................................................................................................................................................................. 27 RE-COMPUTATION OF THE RESPONSE FOR COMPARISON WITH THE CLIENT-SENT RESPONSE AND EXTRACTION OF THE USER-ID. ...................................................................................................................................................................... 27 SERVER ......................................................................................................................................................................... 27 CRYPTOGRAPHY ................................................................................................................................................ 28 5.5 Example cryptography from server to client.......................................................................................... 30 FUNCTION...................................................................................................................................................................... 31 METHOD........................................................................................................................................................................ 31 DESCRIPTION................................................................................................................................................................. 31 COMPONENT.................................................................................................................................................................. 31 SERVER SIDE ENCRYPTION............................................................................................................................................. 31 CRYPT ............................................................................................................................................................................ 31 ENCRYPTION WITH THE USE OF RANDOM SESSION STRING, OF SERVER SECRET AND USER-ID WHICH THE CONFIDENTIAL DATA IS TO BE SENT. ............................................................................................................................. 31 SERVER ......................................................................................................................................................................... 31 SERVER SIDE DECRYPTION............................................................................................................................................. 31 DECRYPT ........................................................................................................................................................................ 31 DECRYPTION WITH THE USE OF RANDOM SESSION STRING, OF SERVER SECRET AND USER-ID WHICH THE CONFIDENTIAL DATA HAS BEEN RECEIVED FROM........................................................................................................... 31 SERVER ......................................................................................................................................................................... 31 CLIENT SIDE ENCRYPTION.............................................................................................................................................. 31 CRYPT ............................................................................................................................................................................ 31 ENCRYPTION WITH USE OF RANDOM SESSION STRING................................................................................................... 31 CLIENT .......................................................................................................................................................................... 31 CLIENT SIDE DECRYPTION.............................................................................................................................................. 31 DECRYPT ........................................................................................................................................................................ 31 DECRYPTION WITH USE OF RANDOM SESSION STRING. ................................................................................................ 31 CLIENT .......................................................................................................................................................................... 31 REMOTE CONTROL............................................................................................................................................. 32 5.6 Synchronize Command.............................................................................................................................. 32 Read Command......................................................................................................................................... 32 Write Command ........................................................................................................................................ 32 Example writing on the remote token..................................................................................................... 34 FUNCTION...................................................................................................................................................................... 37 METHOD........................................................................................................................................................................ 37 DESCRIPTION................................................................................................................................................................. 37 COMPONENT.................................................................................................................................................................. 37 READ COMMAND ........................................................................................................................................................... 37 COMMITREAD .................................................................................................................................................................. 37 IT ENABLES GENERATING THE READ COMMAND BY STATING THE START POSITION AND THE READABLE DATA LENGTH.37 SERVER ......................................................................................................................................................................... 37 WRITE COMMAND.......................................................................................................................................................... 37 COMMITWRITE ................................................................................................................................................................ 37 IT ENABLES GENERATING THE WRITE COMMAND BY STATING THE START POSITION, THE DATA LENGTH AND THE WRITABLE DATA. .......................................................................................................................................................... 37 SERVER ......................................................................................................................................................................... 37 SYNCHRONIZATION COMMAND..................................................................................................................................... 37 SYNCHONIZE................................................................................................................................................................... 37 IT ENABLES GENERATING THE SUYNCHRONIZATION COMMAND FOR ALIGNING THE COUNTER OF THE WRITING NUMBER. ..................................................................................................................................................................................... 37 SERVER ......................................................................................................................................................................... 37 COMMAND EXECUTION.................................................................................................................................................. 37 CMDEXECUTE .................................................................................................................................................................. 37 IT ENABLES THE ACTUAL EXECUTION OF THE COMMAND GENERATED BY THE SERVER ON THE TOKEN.......................... 37 CLIENT .......................................................................................................................................................................... 37 5.6.1 5.6.2 5.6.3 5.6.4 5 6 6.2.1 6.3 6.4 COMMAND EXECUTION CONTROL.................................................................................................................................. 37 CMDRESULT .................................................................................................................................................................... 37 IT ENABLES CONTROLLING AND EXTRACTING THE STATUS AND THE RETURN VALUES OF THE REMOTE COMMAND. ..... 37 SERVER ......................................................................................................................................................................... 37 INTEGRATION ..................................................................................................................................................... 38 6.1 MANAGEMENT OF USER-TOKEN ASSOCIATION................................................................................................... 38 TOKEN INITIALIZATION...................................................................................................................................... 38 6.2 Example token initialization.................................................................................................................... 39 SESSION OPERATION .......................................................................................................................................... 40 SSL OPERATION................................................................................................................................................. 41 7 EXAMPLES ............................................................................................................................................................ 43 AUTHENTICATION.............................................................................................................................................. 43 CRYPTOGRAPHY ................................................................................................................................................ 48 8 APPENDIXES......................................................................................................................................................... 53 SYMMETRIC CRYPTOGRAPHY ............................................................................................................................ 53 AES................................................................................................................................................................... 53 DES................................................................................................................................................................... 54 TRIPLE DES....................................................................................................................................................... 54 HASHING ALGORITHMS...................................................................................................................................... 54 GLOSSARY......................................................................................................................................................... 55 BIBLIOGRAFY .................................................................................. ERRORE. IL SEGNALIBRO NON DEFINITO. 8.1 8.2 8.3 8.4 8.5 8.6 8.7 7.1 7.2 6 1 Preface This chapter describes the contents and the lay-out of this manual and of WebIdentity distribution. 1.1 About this manual This manual describes the WebIdentity product, its operation, its integration into web services and client/server applications. This manual appeals to the software developers and system integrators who are willing to implement projects based on data authentication and confidentiality for web services through the development of ASP pages, JSP pages, Servlet Java and client-server applications at large. 1.2 Environments supported by version 5.0 Version 5.0 of this software does not cover all environments that were supported by version 4.0. Later versions of the software will support such environments. To verify the actual coverage please refer to chapter Requirements 1.3 How to use this manual The basic concept and the architecture of WebIdentity are described herein, as well as its implementation as ActiveX and Java classes and the possible operating instructions. Chapter 1: Preface describes the content and the lay-out of the manual. Chapter 2: Introduction presents WebIdentity features and introduces its practical operation. Chapter 3: Requirements lists the hardware and software requirements for using WebIdentity. Chapter 4: Installation and Configuration describes the necessary steps for installing and configuring WebIdentity. Chapter 5: Features describe the operation and the security specifications of WebIdentity. Chapter 6: Integration describes the macro activities that are necessary for operating WebIdentity in a project for web application development. Chapter 7: Examples provides practical examples for using WebIdentity. Chapter 8: Appendixes o Symmetric cryptography o Hashing algorithms o Glossary o Bibliography 1.4 Assumptions For reading this manual the knowledge of web technologies (ASP, VBScript, JavaScript, JSP, COM, ActiveX, EJB, Java, Servlet) that are used for developing web-based and client/server applications is required. Besides the knowledge of security topics based on symmetric key cryptography is required. A quick introduction to symmetric cryptography is available in Appendix 8.1. 1.5 Font conventions In this manual the following conventions for the use of Fonts are agreed:
The Italics font is used for:
Words taking on a specific meaning in the text beyond their own literal meaning. Words that are introduced for the first time The Courier font is used for:
Sources in HTML, VBScript and JavaScript languages 7 Names of classes and objects File names The font is used for:
Product names Company names Registered Trademarks Interrelated Documents 1.6 Here follows the list of further documentation relating to WebIdentity:
EUTRON, WebIdentity API Reference, 2007 Reference for the programmer of WebIdentity-related applications. EUTRON, WebIdentity Java Developer Documentation, 1998 Electronic guide for the Java developer of WebIdentity in JAVADOC format. The material supplied with WebIdentity is subdivided into software components and documentation; the lot is supplied within the WebIdentity package. 1.6.1 Software components The following software components are enclosed with WebIdentity:
wicli.cab wisrv.cab WIClientInstaller.exe Activex client downloadable with Explorer. Activex server downloadable with Explorer. It is NOT necessary to put it at the end users' disposal: customers can access the website and therefore do not need to download this cab. Setup which attends to installing each component that may be useful for users in possession of a WebIdentity3P key. This setup installs:
the activex client;
the plug-in for each non-Explorer browser abovementioned;
the driver for the WebIdentity3P Token. WIDLClientInstaller.exe Setup which attends to installing each component that may be useful for users in possession of a WebIdentityDL. This setup installs:
the activex client;
the plug-in for each non-Explorer browser abovementioned. WIDriverInstaller.exe Setup of WebIdentity3P driver. This setup is necessary for an Explorer user in possession of a WebIdentity3P token. WIServerInstaller.exe Setup for installing the client and server parts. This setup installs:
the activex server;the activex client;
the plug-in for each non-Explorer browser abovementioned;
the driver for the WebIdentity3P Token. Webidentity-4.0.0.0-
1.i386.rpm WebIdentity Plug-In Client for Linux Wicli.dmg WebIdentity Plug-In Client for Mac OS X 8 1.6.2 Documentation The following documentation is enclosed with WebIdentity:
EUTRON, WebIdentity Developer Guide, 2007 Manual for the WebIdentity programmer. EUTRON, WebIdentity API Reference, 2007 Reference for the programmer of WebIdentity-related applications. EUTRON, WebIdentity Java Developer Documentation, 1998 Electronic guide for the Java developer of WebIdentity in JAVADOC format. EUTRON, WebIdentity Demo, 2004 Examples that introduce WebIdentity features in web-based applications with IIS, ASP and ASPNET. EUTRON, WebIdentity Java Demo, 2004 Examples that introduce WebIdentity features in Java web-based applications with Java 2 Enterprise Edition v1.3 and the use of Java Application Deployment Tool for the illustrative application. 9 1.6.3 Distribution The CD-ROM that is supplied with the WebIdentity SDK contains all necessary software for using and developing web-based and client/server applications with WebIdentity use. 1.7 Feedback The quickest way for getting in touch with EUTRON as regards WebIdentity is sending an email message to the helpdesk: helpdesk@eutronsec.it For any commercial contact it is possible to send an email message to the following address: info@eutronsec.it. Please be reminded that the customer service is exclusively provided to EUTRONs customers who use WebIdentity. No direct assistance is provided to EUTRONs customers customers. 10 INTRODUCTION 2 WebIdentity is a USB device which enables the remote identification of a user in a secure way. The software components that are available with WebIdentity enable integrating the token features into web-based applications. Eutron WebIdentity originated with the intention of making an Internet service user identifiable univocally and guaranteeing access to information contained in the website only and exclusively to the user in possession of a personal hardware device. Even if the Internet environment is the first operating environment which WebIdentity appeals to, it is possible to use it in a generic client-server environment. 2.1 WebIdentityDL: The new model WebIdentity has been recently renewed and the main features of the new device are:
1. HID interface: now WebIdentity is a USB device which exports a HID (Human Interface Device) interface, and therefore the native support of the operative system for accessing the token is used in all Windows operating systems (but also Linux and Mac OS). This makes the installation of a specific driver for the device useless, for the benefit of operating user-friendliness. The previous version was a USB device requiring the installation of a standard supplied driver. 2. Authentication via AES 256: The new WebIdentity token is similar to the previous model from the architectural point of view, but instead of carrying out authentication via the Triple-DES algorithm it now uses the new standard AES in the 256 bit key version. This algorithm ensures an even higher security than the previous version. This new version of WebIdentity has been named WebIdentityDL (WebIdentity driverless). Within this document when this WebIdentity version will be expressly referred to it will be identified with WebIdentityDL whilst the previous version will be identified with WebIdentity3P. The production of the WebIdentity3P tokens has been discontinued but the software supplied with WebIdentity is compatible with both versions and can therefore support both of them. Within this document the model WebIdentityDL will always be referred to, unless the older version is expressly specified. 2.2 Secure authentication in web-based applications The term "authentication" is often used in the broad sense. By authentication the process of verification of a persons identity or of a process identity is meant; within a communication the authentication verifies that the messages coming from a recognized source belong to such a source. The authentication processes that are used with web application nowadays are mainly based on username and password recognition, whether integrated in the HTTP protocol or controlled by the application itself. 2.3 The WebIdentity solution WebIdentity has been designed for supplying a high security strong authentication without employing any complicated and expensive infrastructure. WebIdentity solves all problems connected with username- and password-based authentication systems, that is:
vulnerability: the username and the password are transmitted in plain text mode and are therefore subject to attacks based on packet filtering (sniffing). Improper use: it is not possible to control the number of people using the same username and password. A high security alternative might be the adoption of a PKI (Public Key Infrastructure) which implies a considerable management load, above all within already existing infrastructures. WebIdentity, while ensuring a strong authentication that is comparable with the authentication obtainable from a PKI infrastructure, requires a managing and implementing work load that can be compared with the integration of the username- and password-based application-related authentication. 11 WebIdentity represents the ideal hardware & software solution:
for Strong Authentication of web-based service users for managing protected transactions over the Internet network 2.4 Fields of application The typical WebIdentity user is anybody interested in the protection of web services, that is in protecting access to reserved information and services that are available via a web server. For instance:
customized price-lists download areas for software update management of Internet subscriptions on-line newspapers and magazines The univocal and selective authentication of users enables, among other things, to manage customized user profiles and a really controlled and selective distribution of received information. 2.5 USB Tokens The WebIdentity product features some functional characteristics that make it the ideal solution for secure authentication when accessing restricted resources. WebIdentity can identify with absolute certainty the person who is accessing an Internet website thanks to the use of a microchip. Besides, thanks to the univocal data entered in the production phase each WebIdentity token has been produced in a univocal and unrepeatable way. Thanks to the USB HID interface, WebIdentity affords the advantage of being interfaceable with any available PC without adding any hardware infrastructure. It also offers a reduced dimension that makes it extremely easy to transport, like with a smart card. 2.6 Authentication WebIdentity originated with the intention of making an Internet service user identifiable univocally and guaranteeing access to information contained in the website only and exclusively to the identified and authorized user. The WebIdentity, ActiveX and Plug-In software components exploit the storage and cryptography potential of the WebIdentity hardware key, enabling access to a Web site only and exclusively to a user in possession of a WebIdentity and duly initialized by the Internet service provider. The control on the users identity is carried out via a process requiring the initialization of a token and the implementation of a challenge/response protocol for authentication:
1. 2. Initialization of the WebIdentity device to be supplied to the service user to protect and generation of a database or addition to the existing one of the token identifying information (User-Id) for each associated user. forwarding of server-generated challenge to the client. 3. Verification of initialized WebIdentitys presence on the client; reading and computation of response; forwarding of response to the server for recognition. 4. Verification of response on the server, identification of the user, forwarding of information to the client if the user turns out to be authenticated. 2.7 Cryptography Besides identifying the user, Eutron WebIdentitys technology puts another important possibility at the ISPs disposal:
forwarding of encrypted data over the Internet. Indeed it is rather simple, once the client is identified, to be able to forward the hyper-textual content of the pages and receive the data entered in a form on the client by the user securely, that is to say, encrypted. The operation is always carried out by the ActiveX that come with the WebIdentity solution. 12 2.8 Remote control This feature enables carrying out the reading and writing operation on the WebIdentity remote device. To this end a protocol based on challenge/response has been developed which enables exchanging data (reading and writing of the remote Token) from the client ActiveX to the server ActiveX securely, that is, ensuring confidentiality, integrity and non-replicability of data. This function enables storing on the token any kind of information which might concern the user or the service. This might come in useful for instance with recharge-based, score-based or bonus-based services, for which management is carried out in a centralized or partially centralized way; in this situation it is therefore necessary to retrieve or setup data directly from the token and on the token. 13 3 Requirements To work properly the WebIdentity product requires the processing environment to meet some minimum requisites in terms of installed hardware and software. The requisites are divided into two distinct parts concerning the client and the server. 3.1 Client With Microsoft Windows the client component is realized with an ActiveX for Windows Explorer and with a Plug-In for Mozilla Firefox. This is the list of environments supported by the software 5.0 version:
Operating system o Windows 98SE/ME o Windows 2000 o Windows XP 32 bit o Windows Vista 32 bit Web Browser o Microsoft Internet Explorer 6.0 and 7.0 o Netscape 8.1.3 or higher o Mozilla 1.7.13 or higher o Firefox 2.0 or higher WebIdentityDL also works on XP 64 bit and Vista 64 bit (on AMD64 architecture) with 32 bit browsers. As far as Linux and Mac OS are concerned a future release for supporting WebIdentityDL within such environments is planned for. If only WebIdentity3P is used it is possible to adopt the previous 4.0 version of the software that is supported also by Linux and Mac OS X. The 4.0 version supports the following environments:
Architecture i386 hardware (Microsoft Windows, Linux) o o PowerPC G3/G4/G5 (Mac OS X) Operating system o Microsoft Windows 98SE/ME/NT4/2000/XP o Linux (kernel 2.4 or higher) o Mac OS X Browser web o Microsoft Internet Explorer 3.0 or higher for Windows o Netscape 6.1 or higher for Windows/Linux/Mac OS X o Mozilla 1.6 or higher for per Windows/Linux/Mac OS X o Firefox 0.7 or higher for Windows/Linux/Mac OS X o Camino 0.8 or higher for Mac OS X Version 4.0 does not support WebIdentityDL 3.2 Server The 5.0 version of the WebIdentity software provides a COM interface for Windows 32 bit and 64 bit. At some future date a Java class will also be released for non-Microsoft platforms and for environments supporting Java libraries. If only WebIdentity3P is used it is possible to adopt the previous 4.0 version of the software that also contains the servers Java library. 14 3.3 Compatibility between 5.0 and 4.0 versions The following table sums up the availability or non availability of the support between different software versions on the client and servers side and tokens in use. Server 5.0 WebIdentityDL with Client 5.0 Supported WebIdentityDL with Client 4.0 NOT supported WebIdentity3P with Client 5.0 WebIdentity3P with Client 4.0 Supported Supported Server 4.0 NOT supported NOT supported Supported Supported 15 Installation and Configuration 4 Using WebIdentity requires installing and configuring two different modules: the client and the server. For each system specific software components to install and configure are provided. 4.1 Client WebIdentityDL operation on the client requires the installation of a software component: in Windows environment for the Explorer browser it will be an activex, in all other cases it will be a plug-in. In the event of a WebIentity3p model a driver will also have to be installed. 4.1.1 Example installation of a web page The following HTML code enables installing and updating the ActiveX client of WebIdentity in Explorer automatically:
<object classid="clsid:878A0D61-48D2-11D3-A75D-00A0245382DE"
id="WIDrvCli" codebase="software/WICli.cab#version=4,0,0,0"
VIEWASTEXT>
<embed type="application/x-wicli-plugin" name="WICli" width="1"
height="1" hidden="true">
</object>
The OBJECT1 tag enables inserting in the HTML document the ActiveX univocally identified by means of the class id, which for ActiveX client is 878A0D61-48D2-11D3-A75D-00A0245382DE. The ID attribute identifies the object univocally inside the document by means of a label, thus enabling interaction. The CODEBASE attribute is necessary in case ActiveX is not present on the client. Such an attribute specifies the location (URL) from which the component is downloaded automatically. In addition to the URL it is possible to enter the control version ( #version= ) so that it can be downloaded, if more recent than the installed version. The EMBED tag enables inserting in the HTML document the client WebIdentity Plug-In univocally identified with the TYPE application/x-wicli-plugin tag. For Microsoft Windows the ActiveX WebIdentity client for Internet Explorer and the Plug-In WebIdentity client for browsers derived from the Gecko engine (Mozilla, Netscape, Firefox) are available. Hereunder listed are the various cases and the software that it is necessary to install for using WebIdentity. 4.1.2 EXPLORER USERS IN POSSESSION OF A WEBIDENTITYDL DEVICE WebIdentityDL does not require any drivers; therefore within all operating systems (except for Windows 98) the user just has to connect to the website that employs WebIdentity. The download of the new activex will be managed by the browser (like with the previous example) which will require the user to provide the necessary confirmations. No other operations are required, excepting that of using an Explorer configuration that enables downloading and running signed activex. The name of the cab which contains the activex is wicli.cab 1 At present supported only by Internet Explorer 4.0+ and following 16 4.1.3 EXPLORER USERS IN POSSESSION OF A WEBIDENTITY3P DEVICE For being able to use WebIdentity3P the user needs to install the driver (had it not been previously installed) by using the WIDriverInstaller.exe setup. The setup must be carried out by administrator-level users. The driver is not signed, therefore the user will have to answer affirmatively to the request for installation of a non-signed driver. After installing the driver the user can use the device as a WebIdentityDL user. 4.1.4 FIREFOX (or Mozilla and Netscape) USERS IN POSSESSION OF A WEBIDENTITYDL In order to be able to use the web pages that are protected by the WebIdentity plug-in, download and install the WebIdentity client plug-in: use WIDLClientInstaller.exe. The versions of those browsers for which installation is guaranteed are:
4.1.5 FIREFOX (or Mozilla and Netscape) USERS IN POSSESSION OF A WEBIDENTITY3P For Installing the web pages protected by the WebIdentity plug-in download and install WIDLClientInstaller.exe then install WIDriverInstaller.exe; the order in which these setups are run is irrelevant. It is possible to use one single setup for plug-in and driver by using WIClientInstaller.exe. 4.1.6 WINDOWS 98SE USERS IN POSSESSION OF A WEBIDENTITYDL DEVICE This operating system supports the HID peripherals, but Microsoft does not require any default installation of the support. Anyway Windows 98 installation disk contains the HID driver related to this operating system. The related cab is also available at this address. http://www.eutroninfosecurity.com/shared/test/HID_Win98se/HID_Win98se.zip The setup of the plug-in or of the client activex is analogous to the operations to carry out on the other operating systems. 4.1.7 LINUX USERS Please be reminded that with this release Linux support does not support WebIdentityDL; at present only the software of 4.0.0.0 version supporting WebIdentity3P is available. For Linux the client Plug-in WebIdentity for Gecko browsers is available. For such browsers an rpm packet (webidentity-<version>-<build>.i386.rpm) is available which must be downloaded manually: once the rpm file is downloaded it is possible to use a visual packet manager or the rpm command line utility for manual installation. Use the command rpm -i webidentity-4.0.0.0-1.i386.rpm for installation, rpm -e webidentity for uninstallation and rpm -q webidentity for verifying the installation. 4.1.8 MAC OS X USERS Please be reminded that with this release Mac OS X support does not support WebIdentityDL; at present only the software of 4.0.0.0 version supporting WebIdentity3P is available. For Mac OS X the client Plug-In WebIdentity is available for Gecko browsers. For such browsers a disk file is present
(wicli.dmg) which must be downloaded manually; once downloaded it is possible to load it by double-clicking on the file .dmg, if not loaded automatically. If the operation fails and the downloaded file is not associated as a disk file, it is necessary to execute Information on the file and then choose Disk Copy from the Open with application section. With Mac OS X 10.2+ it is possible to use Open with from the context menu. Once the file is uploaded, open 17 it and run it by double-clicking the packet file wicli.pkg in order to start the installation; then follow the wizard's instructions for completing it. 4.1.9 ADMINISTRATORS PERMITS FOR INSTALLATION With Microsoft Windows NT/W2K/XP, Linux and Mac OS X it is necessary to have administrators privileges for carrying out the installation of the client component. On Windows 2000, XP and Vista the installation of the WebIdentity client component must be carried out at a users level with administrators permits. When using the WebIdentity3P token with Windows 2000 and XP the installation needs to be completed by inserting the token into each of the available USB ports in order to enable every non-administrator user to use the token. In case of Windows XP the following dialog-box will also appear for installing the driver: installation must be carried out without enabling any research in Windows Update (for saving time), then confirm the automatic installation from the following display page; at this point the installation on the USB port will be completed. 4.2 Server The server configuration is strictly dependent on the Web Server that is to be used. Within Microsoft Windows WIServerInstaller.exe of the (ActiveX) server. bit with 32 i386 architecture just run the installation program Within a Java environment the copy of the WEBIDENTITY.JAR library is provided in order for the java applications
(Servlet, for instance) to be able to use the WebIdentity API. It may be necessary to setup a CLASSPATH environment variable for identifying the WebIdentity API. 18 5 Features This chapter describes the content and the features provided by WebIdentity for integrating with web-based and client-
server applications. Integrated features 5.1 The WebIdentityDL device is a secure, portable and user-friendly hardware key with USB interface. The device is characterized by the following technical specifications:
compliant with the USB specifications (Universal Serial Bus) v2.0 low speed devices and HID 1.11. equipped with a univocal serial code for each key: each key is individually customized with a factory pre-set identification code, different for each user. It runs AES 256 bit On Board. It implements secure data storage. The token is provided with about 8KB FLASH memory, processor-internal and externally-accessible only in firmware-controlled mode; besides, no command can modify the serial number. This architecture prevents (i) the possibility to copy the memory from one token to another (it is not possible to clone the token), (ii) the direct modification of the memory content. It implements secure data transmission. The data packets passing through the USB bus are protected with AES cryptography and each packet includes a random value so as to avoid any possibility to read and identify the transit commands and information. It implements the http communication cryptography with the Blowdish algorithm with 256 bit key. Self-powered: it does not use any internal batteries nor any external power supply. Figure 5.1 displays the schematic make-up of the WebIdentity hardware token. USB Connector Type A USB Controller Microchip +
Flash Memory AES 256 Write only memory Figure 5.1 Make-up of WebIdentity token The AES 256 on board operations have been designed for ensuring maximum security; indeed during the initialization phase the AES key is stored in the write-only memory and used on board for AES computation. As the key is write-only and executable, it is impossible to extract it from the token and therefore to obtain it unlawfully. Any programs designed for monitoring the data transfer from the token to the PC would not be able to trace back the symmetric key contained in the token in any way. The flash memory is inside the WebIdentityDL processor; it can be accessed via the implemented commando, that is, it is not possible to access data directly; in particular it is not possible to read the AES keys as there is no command that may carry out such an operation. Please be reminded that concept of write-only memory with on-board key computation is available also on the WebIdentity3P model, which does not use the AES algorithm but the Triple DES 2EDE algorithm. 19 On this key a good part of data is assigned to an eeprom memory which, even if external to the processor, is encrypted with a key contained in the processor internal memory space. This makes reading the eeprom memory useless as the cryptography key is not revealed. It is also impossible to clone it because each WebIdentity3P device has a cryptography key which resides on the processor-internal memory partition and is different for each device. 5.2 WebIdentity contents Three essential items of information are stored securely within the microchip memory, both for WebIdentityDL and for WebIdentity3P:
1. the Label is inserted in the initialization phase and exclusively used for identifying the WebIdentity token on the USB bus. It is represented by a string that usually identifies the web service. 2. The User-Identifier (User-Id1) generated the initialization phase and dependent on the key personal data ad univocal data. The personal data can be made up by any information which might represent the user, for instance, name and surname; the univocal data is represented by the Token Serial Number (univocal serial number assigned to each WebIdentity device). 3. The AES 256 key (3DES per WebIdentity3P) generated in the initialization phase, dependent on the Server Secret (illustrated in the following charter, which can be considered as the generator of all token keys) and on the User-Id; it is stored in the write-only memory partition; the AES key is the symmetric key. The computation of the AES key is obtained by means of a hashing and AES cryptography procedure. hashing of User-
Id and AES computation using the Server Secret as a key. A brief introduction to the hashing algorithm is present in appendix Errore. L'origine riferimento non stata trovata.. The token secret (dependent on the Server Secret) is therefore given by the AES-Key (symmetric key) used in the challenge/response operations and stored in the write-only memory of the microchip itself. Its computation typology ensures the Server Secret and consequently the integrity of the whole service. In other words if the key entered in the token was recognized, it would not be possible to trace the Server Secret any way. The key of the token cannot be accessed as long as one the following events occurs at least:
1. AES is fully violated 2. The whole content of the WebIdentity chip memory is violated The former case appears highly improbable. The latter case might happen only by using extremely expensive devices. In the latter case a large economic investment might bring to the violation of a single device, not of the whole system, therefore the Server key is secure as long as AES is not fully violated. Figure 5.2 describes the information contained in the WebIdentity token and their connections. 1 Also named PIN. 20
- SERVER SECRET
- USER-ID S E A
H S A H
- User Data
- Token Serial Number Label AES KEY USER-ID Figure 5.2 Information provided in the WebIdentity token 21 5.2.1 Server Secret The protection model offered by WebIdentity includes the use of one unique secret termed Server Secret (inside the WebIdentity SDK it is termed Server Password). The Server Secret is used during WebIdentitys processing for authentication, cryptography and remote control on the server side; it is also used during the initialization phase relating the WebIdentity hardware devices. Such a secret makes it possible for the service provider to recognized all and only its own WebIdentity keys, and consequently the customer who owns them. Practically speaking, the Server Secret is an alphanumeric string that is chosen in the web service development phase. Il Server Secret is converted into a AES 256 key or DES 2EDE Triplo; an ideal key can be produced by using a string with at least 43 characters, random chosen among the letters of the English alphabet (lower-case and upper-case) and numbers. The security of the Server Secret is at the web server developers care who must prevent access to non-authorized persons; for instance, if the Server Secret is stored in the application DB it is advisable to encrypt it. However it is important to take all the necessary precautions for making access to the application as secure as possible, as security depends on the Server Secret, which must be accessible on the server service side. The Server Secret is used as a AES 256 key (3-DES for WebIdentity3P) for generating the secret key of each token. The input text of the AES computation is the User-ID hashing. Therefore each user is assigned a different key, which guarantees the following security level:
1. by knowing the User-ID it is impossible to calculate the token secret key if the Serve Secret is not known 2. by knowing the User-ID and the token secret key (the latter data being virtually inaccessible as reported above) it is impossible to trace the Server Secret. 22 5.3 Operation For operating properly it is necessary to structure a website in such a manner as to be able to manage the following. When a user is connecting to a protected web area, the WebIdentity Server requires the insertion of the device in the client machine in order to verify the information contained therein. The operation is carried out with a Challenge/Response protocol which enables authenticating the client without the information contained in the token being transferred through the network. All WebIdentity-related information exchanged between the server and the client do not require any particular communication protocol and therefore it is possible to use the same protocol of the application. For web-based applications all transactions carried out for authentication, cryptography and remote control are managed with http protocol, which is therefore portable and transparent for the various transfer systems. For client/server applications it is possible to use a DCOM or CORBA for message exchange. The following paragraphs exemplify WebIdentity authentication, cryptography and remote control operations. In the following paragraphs the authentication mechanism is illustrated; no clear distinction is made between the functions operated by the WebIdentity software and those carried out by the client application (typically a web application): here attention is drawn to the operating process. As from paragraph 3 an example is provided about how to carry out authentication with a web application; at this point the operations of the WebIdentity software and those relating to the infrastructure will be manifest. 5.4 Authentication The WebIdentity remote identification mechanism requires a client/server architecture. Client and server establish a challenge/response dialogue, thus enabling the users remote identification and guaranteeing secure access to confidential areas/information within the WebServer. The operations involved are implemented by a ActiveX or by a Java class on the server side component, whilst for the client side component by an ActiveX or a Plug In which communicates with the hardware token. The following lay-out sums up the authentication operations via WebIdentity in a web ambit:
23 Computer e s n o p s e R t e G
) 3
(1) Request for Challenge
(2) Return Challenge a s k e d U s er-I D R e s p o n s e + m
) 4
(5) Server Response = AES( challenge, AES-key ) Figure 5.3 Sequence Challenge/Response for authentication operation 1. In the first phase the client (browser) sends an http request to the web server (get, post). 2. The web server responds to the request by generating a challenge which is sent to the client. 3. The client queries the token by transmitting the challenge sent by the server for generating the response. 4. The token computes the response on board by running: response = AES ( challenge, AES-key ) and then the client sends the server the response + user-id in encrypted format. 5. The server carries out all necessary operations for recalculating the response. As described at figure 5.4 the server computer the AES key (AES-key) locally by running a hash of the User-Id and then an AES computation by using the Server Secret as a key. The result, that is the client secret key, is used as a key for carrying out the AES of the challenge previously sent by the client. The result is the response recalculated by the server: if it turns out to be identical to the response sent by the client it means that the client is in possession of a valid token, that is, generated and initialized by the same service and therefore containing the same Server Secret. From a conceptual point of view, the computation of the client secret key can be considered as a hashing. 24 Client Server AES-Key Challenge Hashing AES AES Client Response Server Response Figure 5.4 Procedure for client authentication User-Id Server Secret The challenge is generated by the ActiveX of the server and is termed Random Session String. The Random Session String can depend on the time, on an id-session which typically all application servers make available for identifying the session, and on a string which, if present, contributes to the generation of the Random Session String. Having a string dependent on time and on external pseudo-random variables originates from the need to have univocal and non-
repeatable transactions. They are univocal for preventing two transactions from being identical; non-repeatable for preventing the communication from being re-proposed in the attempt to deceive the server (replay avoidance). It is to be noticed that the Random Session String can be sent in plain-text format without jeopardizing security absolutely. 5.4.1 Example log-in from a web page The following example sums up the essential steps for integrating the authentication with WebIdentity into a web-based application with ASP; hereunder reported are only the descriptions that are strictly necessary for understanding the mere working; for a complete example please refer to section Errore. L'origine riferimento non stata trovata.. The first step to take at the beginning of the transaction, after the clients request for a new connection, is the generation of a challenge string by the server including the relevant login page. 1
Session("SessionString") = WISrv.InitRndSessionString (true, Session.SessionID, "FREE-STRING") 1. ASP-VBScript code on the server side that is necessary to the generation of the Random Session String dependent on time (with true as first parameter, the time value is used as one of the components for the generation of the Random Session String), on the session id (Session.SessionID being the variable provided by ASP for identifying the session) as second parameter and on a random-chosen string as third parameter. The Random Session String is also stored in the session variable Session("SessionString") for being used in the client response check. Once the client receives the login page containing the challenge the user must insert the token and proceed to the authentication request. The client carries out the computation of the response by means of the token and sends it to the server. The following code describes an operating example for the computation of the response in client-side JavaScript code. 25 1
2
3
4
5
function SendPIN()
document.WIDrvCli.RndSessionString =
document.WIDrvCli.Label = "<%= Application("wi_Label") %>"
document.WebIdData.PIN.value = document.WIDrvCli.ReadPin();
"<%= Session("SessionString") %>"
// Send PIN to server document.WebIdData.submit();
1. Client-side JavaScript function used for the generation and forwarding of the response that is called for by the login page following an authentication attempt. The function must be called for by the web page following an event that occurred by pressing the website enter key, for instance. 2. 3. Initialization of the client object with the Random Session String generated and sent by the server; the entry RndSessionString is a variable of the client ActiveX inside the HTML document; the Session("SessionString") entry is interpreted by the sever side and then replaced with a Random Session String string. Initialization of the client object with the token identification Label; the Label entry is a client ActiveX variable inside the HTML document; the entry Aplication("wi_Label")is interpreted by the server side and then replaced with the label chosen for the service. 4. Call of ReadPin method by the client ActiveX inside the HTML document for the generation of the response (response + masked User-Id) to be sent to the server; the response value is assigned to the PIN variable contained in the WebIdData Form inside the HTML document. 5. Explicit call to the submit of the WebIdData form for actual forwarding via a GET or a POST of the PIN variable containing the response. After the server has received the response from the client it must verify its authenticity. The following server-side ASP-VBScript code describes the verification part of the response authenticity. WIDSrv.Password = Application("wi_Password") WIDSrv.RndSessionString = Session("SessionString") WIDSrv.DecryptPIN( Request.Form("PIN") ) If WIDSrv.GetLastError() <> 0 then Response.Redirect "index.asp"
endif 1
2
3
4
1. 2. Initialization of the server object with the Server Secret; the Password entry is a server ActiveX variable inside the ASP page; the Application("wi_Password") entry is an application variable maintained by ASP, where the Server Secret value has been previously stored. Initialization of the server object with the Random Session String generated at the start of transaction; the RndSessionString entry is a variable of the server ActiveX inside the ASP page; the Session("SessionString") entry is a session variable maintained by ASP and used for storing the Random Session String. 26 3. Call of DecryptPIN method of the server ActiveX for decrypting the response sent by the client and returned by the call to Request.Form("PIN"). As illustrated in figure 5.4 the server computes the response with the User-Id and the Server Secret again. If the verification is successful the User-Id is stored in the PIN variable of the server ActiveX. 4. With the call to GetLastError the correct execution of the la test call to the server ActiveX is checked;
in this case the response decryption is checked. In this case the user is verified for the possession of a WebIdentity token properly initialized by the same service (that is, initialized with its Server secret Application("wi_Password")). Table 5.4 Association of software functions /methods for authentication. Function Method Description Component Challenge Generation InitRndSessionString Generation of time-variable Server Response Computation ReadPin Response Verification DecryptPin Random Session String. Computation of response by using the WebIdentity token Re-computation of the response for comparison with the client-
sent response and extraction of the User-Id. Client Server 27 5.5 Cryptography With WebIdentity it is possible to execute web page encryption; in particular it is possible to encrypt single items of information both from the server towards the client and vice versa. Indeed some ad hoc scripts are used both on the server side and on the client side; they enable the server to encrypt the confidential information to be sent to the client and to decrypt the received information; on the client side they enable decrypting the information received by the server and encrypting the information to be sent. This way it is at the developers discretion to choose which information is confidential and which is not. In order to execute the WebIdentity encryption and decryption a symmetric algorithm named Blowfish [SCH96] is used. Blowfish uses a session key that is shared between the client and the server; it is generated by WebIdentity each time this is requested. The session key in use is 256 bit type; it is generated in run-time mode both by the server and by the client. The client side generates the Blowfish symmetric key on board by using the AES 256 key that is stored in the token
(3DES for WebIdentity3P) and the Random Session String generated and received by the server; the server generates the symmetric key with the User-Id provided in the authentication phase, the Server Secret stored by the server and by the Random Session String generated by the server itself. Figure 5.5 describes the process that is necessary for computing the session key on the client side and on the server side. Here follows the formula used for the session key computation. Blowfish Key = AES ( AES-Key, Random Session String ) The Random Session String can depend on time, on a session-id (optional but strongly recommended) which typically all application servers put at disposal for identifying the session; it can also depend on a password (optional) which, if present, contributes to the generation of the Random Session String. The generation of the Random Session String can be different for each session but also when sending each page; important is that the same value is used for completing the challenge response operations; for instance when the server sends the client an encrypted data with a Random Session String the client must use the same Random Session String generated by the server for decrypting the data. Client Server AES-Key Challenge Hashing AES AES Input Data Blowfish
- Crypt
- Decrypt Output Data Blowfish
- Crypt
- Decrypt Output Data 28 User-Id Server Secret Input Data Figure 5.5 Procedure for data cryptography 29 5.5.1 Example cryptography from server to client The following example illustrated the essential steps to take for integrating the WebIdentity cryptography into a web-
based application with ASP; the following example shows the passage of an encrypted data from the server to the client;
only the parts that are strictly necessary for describing the operation are reported hereunder; a complete example is provided at section Errore. L'origine riferimento non stata trovata.. From the server side (ASP-VBScript code on server side) just a call to the Crypt method is necessary for encrypting the data in order to send it to the client. 1
2
3
4
WIDSrv.pin = Session("user_PIN") WIDSrv.RndSessionString = Session("SessionString") WIDSrv.password = Application("wi_Password") CryptConfidentialData = WIDSrv.Crypt( ConfidentialData ) 1. 2. 3. Initialization of WebIdentity server object with the User-Id transmitted during authentication by the client and stored in the session variable Session("user_PIN"); the entry Pin is an ActiveX server variable. the entry Initialization of RndSessionString is a variable of the server ActiveX; the Session("SessionString") stores the previously generated Random Session String. the WebIdentity server object with the Random Session String;
Initialization of the server object with the Server Secret; the Password entry is a server ActiveX variable inside the ASP page; the Application("wi_Password") entry is an application variable maintained by ASP, where the Server Secret value has been previously stored. 4. Call of the Crypt method of the server ActiveX for encrypting the data to send to the client variable encrypted is
(ConfidentialData). CryptConfidentialData to be transmitted to the client. vbscript stored value The the n From the client side (Javascript code on the client side ) just a call to the Decrypt method is necessary for decrypting the data sent by the server. 1
2
3
document.WIDrvCli.RndSessionString =
"<% = Session("SessionString") %>";
document.WIDrvCli.Label = "<% = Application("wi_Label") %>";
ConfidentialData = document.WIDrvCli.Decrypt("<%= CryptConfidentialData %>");
window.document.write(ConfidentialData);
1. 2. Initialization of the WebIdentity client object with the Random Session String generated and sent by the server; the entry RndSessionString is a variable of the client ActiveX inside the HTML document; the Session("SessionString") entry is interpreted by the sever side and then replaced with a Random Session String. Inizializzazione of the client object with the Label for identifying the token; the Label entry is a client ActiveX variable inside the HTML document; the entry Application("wi_Label") is interpreted by the server side and the replaced with the label chosen for the service. 3. Call of the Decrypt method of the server ActiveX for decrypting the data sent by the server
(ConfidentialData). In this case the decrypted value is displayed with a call to the Javascript Write function inside the HTML page. Table 5.5 Association of software functions / methods for cryptography. 30 Function Method Description Component Server side encryption Crypt Server side decryption Decrypt Encryption with the use of Random Session String, of Server Secret and User-Id which the confidential data is to be sent. Decryption with the use of Random Session String, of Server Secret and User-Id which the confidential data has been received from. Client side encryption Crypt Encryption with use of Random Session String. Client side decryption Decrypt Decryption with use of Random Session String. Server Server Client Client 31 5.6 Remote control The remote control feature and in the case in point the possibility to read from and write on the WebIdentity token memory is carried out with simple calls to the server ActiveX methods for creating the desired command and with the call of a client ActiveX method for the actual execution of the requested command. The command and all the necessary information for execution are encapsulated inside an encrypted string by the server ActiveX and decrypted and executed by the client ActiveX. The response containing the command status and all that concerns the result is encapsulated into a string encrypted by the client ActiveX and decrypted and controlled by the server ActiveX subsequently. The commands that it is possible to execute on the token are the synchronization between the server and the token, the reading of the remote token memory and the writing into the remote token memory. 5.6.1 Synchronize Command A counter has been introduced for preventing write commands from being reused on the key, as they might be contained in scripts that are locally stored on the computer. This counter is incremented at each reading on the token and it is necessary to state the value subsequent to the current one at each writing attempt. The Synchronize command enables synchronizing such a value, that is, knowing which number will be associated during the next writing into the memory. During the authentication phase, in addition to the authentication itself the writing counter is also synchronized, therefore it should not be necessary to use the Synchronize command explicitly unless in case of special needs. The response of the synchronize command is an object containing the value of the progressive content on the remote token. 5.6.2 Read Command The Read command enables reading from the remote token the full memory area or a specific memory area. The available memory on the token is about 8 KB. In the read command the start position of the reading and the length of readable data is indicated. The response of the read command is an object containing the operation result, the initial position of said data, the length of the read data and the read data themselves. 5.6.3 Write Command The Write command enables writing on the remote token the full memory area or a specific memory area. For security reasons a progressive counter is used for writing management; it prevents the repeated execution of the same command. In the write command the value subsequent to the current progressive value is specified, as well as the start position for writing, the writable data length and the data themselves. The write command response is an object containing the result of the operation with the counter value for any subsequent writing operation. All commands and information exchanged between the client and the server are encrypted with Blowfish following the same procedure that is described under section Errore. L'origine riferimento non stata trovata.. 32 The following layout illustrates the operating sequence for the remote control:
WI Client WI Server Computer e t u c e x E d n a m m o C
) 3
(1) Request
(2) Require A) B) C) Synchronize Read Write + Data Command b er m S y n c hro niz e n u b er w ritte n d ata R e a d d ata m N u A ) B ) R e s p o n s e
) 4
C ) Server Figure 5.6 Challenge/Response Sequence for remote control 1. In the first phase the client sends a request to the server. 2. The server answers the request by generating a response containing the request for a command in the shape of an encrypted string; these are some possible commands:
a. Synchronize enables synchronizing the server with the progressive number of the remote token b. Read enables carrying out reading operations from the token memory c. Write enables carrying out writing operations on the token; together with the command also the writable data is transmitted 3. The client decrypts and interprets the string transmitted by the server and executes the command requested. 4. The client stores the result of the command into an encrypted string and sends it to the server, which can control the execution of the command; the response depends on the type of requested command and is described by the following list:
a. The response to the Synchronize command is the progressive number stored by the token. b. The response to the Read command is the information requested by the token memory. c. The response to the Write command is the operation status. 33 5.6.4 Example writing on the remote token The following example sums up the essential steps to take for using the writing features on the remote token. Hereunder reported are the parts that are strictly necessary for the description of the operations. The first step to take is the generation by the server side (server side ASP-VBScript code) of the write command; it is possible to write on the remote token in the desired location, therefore the parameters for the write command are the start position where data and data length are to be written. 1
2
3
4
5
1. 2. 3. 4. Var StartPosition, Length, DataString StartPosition = 1 Length = 4 DataString = "DATA"
WIDSrv.pin = Session("user_PIN") WIDSrv.RndSessionString = Session("SessionString") WIDSrv.password = Application("wi_Password") WIDSrv.SyncNumber = Session("wi_SyncNumber") CmdString = WIDSrv.CommitWrite(StartPosition, DataString, Length);
Initialization of WebIdentity server object with the User-Id transmitted during authentication by the client and stored in the session variable Session("user_PIN"); the entry Pin is an ActiveX server variable. Initialization of the server object with the Random Session String; the entry RndSessionString is a variable of the server ActiveX; the Session("SessionString") entry stores the previously generated Random Session String. Initialization of the server object with the Server Secret; the Password entry is a server ActiveX variable inside the ASP page; the Application("wi_Password") entry is an application variable maintained by ASP, where the Server Secret value has been previously stored. Initialization of the server object with the Sync Number; the SyncNumber entry is a server ActiveX variable;
the Session(wi_SyncNumber) entry is a session variable maintained by ASP, where the Sync Number value has been previously stored. The Client and the Server can synchronize the Sync Number via the authentication procedure or via the explicit synchronization remote command. 5. Call of CommitWrite method of server ActiveX for generating the write command; the first parameter is the start position where data is to be written, the second parameter is the writable data itself and the third parameter is its length. On the client side (client side Javascript code) it is enough to call the CmdExecute method of the WebIdentity client ActiveX for actually executing the command. 1
2
3
4
document.WIDrvCli.RndSessionString =
"<% = Session("SessionString") %>";
document.WIDrvCli.Label = "<% = Application("wi_Label") %>";
CmdResultString = WIDrvCli.CmdExecute( "<%= CmdString %>" );
if ( WIDrvCli.GetLastError() != 0) {
alert( WIDrvCli.GetLastErrorDescription() );
34 1. 2. Initialization of the WebIdentity client object with the Random Session String generated and sent by the server; the entry RndSessionString is a variable of the client ActiveX inside the HTML document; the Session("SessionString") entry is interpreted by the sever side and then replaced with a Random Session String. Initialization of the WebIdentity client object with the Label for token identification; the Label entry is a client ActiveX variable inside the HTML document; the entry Aplication("wi_Label") is interpreted by the server side and then replaced with the label chosen for the service. 3. Call of ActiveX client CmdExecute method for executing the command; the transmitted parameter represents the string generated by the ActiveX WebIdentity server CommitWrite method. The result of the operation is stored in the CmdResultString Javascript variable for being sent to the server as an operation confirmation. CmdExecute executes the specified command inside the encrypted string. 4. With the GetLastError call it is possible to control the result of the write command for notifying the client in case the problem requires an intervention by the user, for instance token insertion, and therefore repeat the operation. The last step necessary for completing the remote write operation is the control by the server of the result of the operation carried out by the client (server side ASP-VBScript code). The control is carried out by calling the ActiveX server CmdResult method which returns an object describing the operation status and sums up the operations executed on the remote token. 1
2
3
4
5
1. 2. 3. Dim ObjRemoteCmdResponse WIDSrv.pin = Session("user_PIN") WIDSrv.RndSessionString = Session("SessionString") WIDSrv.password = Application("wi_Password") Check of the result (CmdResultString) sent from the client Set ObjRemoteCmdResponse = WIDSrv.CmdResult( CmdResultString ) If ObjRemoteCmdResponse.status <> 0 then Response.Redirect "error.htm"
Response.End End If Initialization of WebIdentity server object with the User-Id transmitted during authentication by the client and stored in the session variable Session("user_PIN"); the entry Pin is an ActiveX server variable. Initialization of the server object with the Random Session String; the entry RndSessionString is a variable of the server ActiveX; the Session("SessionString") entry stores the previously generated Random Session String. Initialization of the server object with the Server Secret; the Password entry is a server ActiveX variable inside the ASP page; the Application("wi_Password") entry is an application variable maintained by ASP, where the Server Secret value has been previously stored. 4. The call to the ActiveX server CmdResult method for the actual control of the operation executed by the client ActiveX on the remote token. The trasnmitted parameter represents the string generated by CmdExecure of the operation result. The return value represents a RemoteCmdResponse type object, describing the operation carried out and the result status. the client ActiveX which encapsulates 5. For controlling the operation result it is just necessary to control the Status variable of the ObjRemoteCmdResponse object that is returned by the CmdResult. 35 36 Table 5.6 Association of software functions / methods for remote control. Function Method Description Component Read command CommitRead It enables generating the read command Server by stating the start position and the readable data length. Write command CommitWrite It enables generating the write command Server by stating the start position, the data length and the writable data. Synchronization command Synchronize It enables generating the synchronization command for aligning the counter of the writing number. Server Command execution CmdExecute It enables the actual execution of the Client command generated by the server on the token. Command execution control CmdResult It enables controlling and extracting the status and the return values of the remote command. Server 37 Integration 6 The integration of WebIdentity into an existing project or its adoption into a new project includes a sequence of operations to carry out for identifying the necessary points on which work is to be focused. First of all it is necessary to identify the positions inside the application where a control of the connected user identity is required and of how such a user can interact with the application. It is therefore necessary to create a connection between the user and the WebIdentity token by entering a reference into the user profile and positioning the user authentication scripts where necessary. It is important to choose the Server Secret in an imaginative way so that it is not "guessed" easily. For a secure choice it is possible to use a random string with a length of at least 52 characters consisting of upper-case letters, lower-case letters and numbers. This instruction is given for providing a key with a bit information quantity that corresponds to the AES 256 bit key used by WebIdentityDL. The location where to store and protect the Server Secret must also be chosen; it is also necessary to choose a Label for identifying the service and therefore for distinguishing it from other services; its value can be unique for the whole application or it can have different values for the same application for special needs. The application part that requires more attention is the token initialization (a necessary operation for using the token) which must be carried out outside the application logic preferably. Another important consideration is the possibility to maintain the user status inside the transaction in order to be able to manage the authentication in one single service point; this is possible with the aid of session persistence provided by the application server as described in the next paragraph. Lastly, some expedients are not to be neglected, such as the security-related expedients, in particular the possibility to associate the client strong authentication provided by WebIdentity with the server strong authentication provided by SSL; such complementary feature is illustrated hereunder.5 6.1 Management of user-token association To associate the token to its own user a new field shall be inserted inside the user database: it is the User-Id related to the WebIdentity token returned during the token initialization phase; this way each single user will be associated with the relevant WebIdentity token for service access. In addition to the User-Id field it will be possible to insert other fields containing information relating to the policies
(expiry dates, restrictions, etc.) made out for creating more complex user profiles. It is also possible to enter the information relating to the Label and the Server Secret in the database for making the application independent of the specific service; this way it will be possible to use the same web service scripts or programs for various web applications. It is also possible, according to the case, to associate the WebIdentity key-based authentication with a further protection including the insertion of an alphanumeric string (Password) for obtaining a two factor authentication, that is:
1. 2. the first factor is possessing something the second factor is knowing something Therefore for accessing the service it is necessary to possess a hardware token and know a password. A typical example is the Bancomat (cash dispenser) working; for being operated it requires knowing the password and possessing a Bancomat card. 6.2 Token initialization The key initialization represents the implementation start-up of a web-based WebIdentity-protected service; by using the libraries provided with the WebIdentity SDK it is possible to initialize the keys by univocally associating them with the protected service and then with each user authorized to the service in question. The key initialization phase associates one single WebIdentity key with one service and one user univocally. For initializing the keys it is necessary to use the WebIdentity server ActiveX after duly initializing it with the following parameters:
Label A label used for identifying the token on the USB bus, thereby identifying the service 38 Server Secret1 Secret of the server for security control User Data Identifying data of the user; for instance name, surname, etc. As described by figure 5.2 the Label, the Server Secret and the User Data are used for computing and initializing the WebIdentity token. The label is inserted and used for identifying the token; the Server Secret is the secret of the server and jointly with the User-Id contributes to the creation of the symmetric key, which is the secret part of the token; the User Data is the data of the user and jointly with the Token Serial Number it contributes to the creation of the User-Id. The resulting data is entered in the write-only memory of the WebIdentity key. Special attention must be given to the application for the token initialization, as during the generation phase the server side ActiveX must be used, together with the Server Secret; if used on an insecure channel this might seriously jeopardize the application security. Differently from authentication and encryption, the initialization just requires using the Server ActiveX after duly initializing it with the Server Secret. The ideal implementation might be a standalone application expressly prearranged for ensuring the Server Secret security and confidentiality. If a web-based application is used, it is necessary to adopt some expedients for guaranteeing the Server Secret protection; for ensuring confidentiality it is possible to use the HTTPS or WebIdentity, for authentication security a client SSL3 or WebIdentity certificate can be used instead. 6.2.1 Example token initialization This example clearly illustrates the sequence of necessary operations for writing a procedure for WebIdentity token initialization. The example is realized HTML with Javascript, therefore it is possible to use a browser (Internet Explorer) for execution. The WebIdentity server ActiveX is used after being downloaded and automatically initialized by the browser. The HTML page requires inserting the Server Secret, the Label and the User Data as requested for initialization. 1
2
3
4
5
<html>
<head>
<title>Token Initialize</title>
</head>
<body>
<object classid="clsid:A811A602-4655-11D3-A75A-00A0245382DE" id="WIDrvSrv"
codebase="software/WISrv.cab#version=4,0,0,0" VIEWASTEXT>
</object>
<script language="JavaScript">
function InitToken()
WIDrvSrv.Label = window.TxtLabel.value;
WIDrvSrv.Password = window.TxtPwd.value;
// Initialize Token window.TxtUserId.value = WIDrvSrv.InitDongle( window.TxtUser.value );
</script>
<p>Server Secret</p>
<input id=TxtPwd name=TxtPwd size=24 value=""><br>
1 Also called Server Password. 39
<p>Label</p>
<input id=TxtLabel name=TxtLabel size=24 value=""><br>
<p>User Data</p>
<input id=TxtUser name=TxtUser size=24 value=""><br>
<input type="button" language="javascript" onclick="return InitToken()"
value="Init Token"><br>
<p>User-Id</p>
<input id=TxtUserId name=TxtUserId size=50 value="">
</body></html>
1. Declaration of the WebIdentity Server ActiveX object by the HTML OBJECT tag; the OBJECT1 tag enables inserting in the HTML document the ActiveX univocally identified by means of the class id, which for the client ActiveX is 878A0D61-48D2-11D3-A75D-00A0245382DE. The attribute identifies the object univocally inside the document by means of a label thus enabling interaction. The CODEBASE attribute is necessary in case ActiveX is not registered on the current machine. Such an attribute specifies the location (URL) from which it is downloaded. In addition to the URL it is possible to enter the control version ( #version= ) so that it can be downloaded, if more recent than the installed version. 2. Javascript InitToken function used for initializing the token. 3. 4. Initialization of the server object with the Label for token identification; the Label entry is a server ActiveX variable inside the HTML document. Initialization of the server object with the Server Secret; the Password entry is a server ActiveX variable inside the HTML document. 5. Call to ActiveX Server InitDongle method for the actual initialization of the hardware token; the parameter that is transmitted is the User Data entered in the HTML form; the User-Id that is returned by the InitDongle is assigned to the TxtUserId variable of the HTML form for display. The example illustrated below the association of the (token) User-Id with the user profile has been left out, as previously explained at paragraph Errore. L'origine riferimento non stata trovata.. However the user-token association is also important as it enables identifying the user following authentication. 6.3 Session operation WebIdentity requires the use of certain server side variables such as, for instance, the Label, the Random Session String etc. For an easy management of such variables it is possible to use the session feature, which is available in all application servers nowadays. In addition to the server side variables it is possible to store also the user status, so as to be able to manage the authentication phase just on one application point or in specific areas of the service itself. However it is possible to implement the authentication at each step (page) if this turns out to be necessary. Using the session is a very useful method for managing the persistence of data between one page and another but it requires a mechanism which enables interrupting the session on request or after a certain time lapse; it is therefore advisable to insert even in each page the possibility to run the logoff manually on the users request and to configure the session timeout suitably inside the application server or the web server (e.g. IIS) avoiding too small values, which hinder the service usability, as well as too big values which might jeopardize security in some cases. 1 At present supported only by Internet Explorer 4.0+. For Netscape it is necessary to use a Javascript for installing the relevant Plug-In. 40 6.4 SSL operation The components or properties characterizing a system for secure information exchange based on cryptography are data confidentiality, client / server authentication and information integrity. Confidentiality means that the exchanged information is not understood by anybody outside the people involved in the transaction. Integrity means that particular function which enables guaranteeing that personal data is original, that is, it has not been modified in any way by the version sent by the sender. It is to be noticed that integrity can be combined with confidentiality but also it may not; if information is not confidential it can be transmitted in plain text mode but the main thing is that it must be possible to check that it corresponds to the original message exactly. Client secure authentication means the possibility to check and control for certain that the client is what it declares to be and therefore its authenticity. Server secure authentication means the possibility for the client to verify for certain that the interlocutor server is actually what it declares to be and not, for instance, another server simulating the requested server. Using WebIdentity provides secure client authentication and confidentiality. To guarantee also the other two security components, one possible standard-based solution is using SSL (Secure Sockets Layer) which manages secure server authentication, integrity and confidentiality. Therefore the two solutions can be considered complementary and in a position to provide an ideal solution for confidentiality, secure client authentication, secure server authentication and integrity. Two possible operating solutions with SSL are displayed in the following table:
Confidentiality Client Authentication Server Authentication Integrity Webidentity SSL Webidentity SSL Combination 1 Combination 2 In the first combination WedIdentity is used for client strong authentication and SSL for confidentiality, server strong authentication and integrity. In point of fact the whole SSL potential is used with the addition of client authentication which SSL1 does not provide; in such a combination, development and integration time is reduced to a minimum, as the modifications to bring about are limited to the management of authentication whilst confidentiality is provided by SSL in a transparent mode. In the second combination WebIdentity is entrusted with data confidentiality and client strong authentication whilst SSL is to provide server strong authentication and integrity. In this case WebIdentity cryptography function is used for encrypting single critical items of information, as distinct from SSL which encrypts everything or nothing. It is also to be considered that WebIdentity encryption enables keeping the information secure even when this is stored in the browser cache or stored locally: indeed, for displaying the pages that have been stored locally in encrypted format it is necessary to insert the token, on the contrary case their content would be unreadable as far as the WebIdentity encrypted 1 SSL version 2 41 parts are concerned. In the second combination, for adding the WebIdentity confidentiality feature it is necessary to write ad hoc scripts for managing the encryption from the server side with the client side decryption and vice versa, that is to say, a greater integration effort. Security at large It is important to notice that adopting solutions that can provide encryption for guaranteeing confidentiality, authentication and integrity is just one of the aspects concerning the overall security of a web-based or client-server service. Some other important aspects are for instance the expedients to adopt during the actual implementation of the service , such as for instance the control of subjects for information exchange; a typical error is buffer overflow, which enables executing a code on a remote service under special circumstances. Attention must also be given to constant and timely updating of the web server and of the application server by downloading the relevant available updates and patches. Finally it is important to adopt a firewall system for protecting the web services and for avoiding any attacks directed at protocol vulnerability. Security at large It is important to notice that adopting solutions E importante notare che ladozione di soluzioni in grado di fornire crittografia per garantire confidenzialit, autenticazione e integrit sono solo alcuni degli aspetti che riguardano la sicurezza generale di un servizio web-based o client-server. Altri aspetti importanti sono per esempio gli accorgimenti da adottare durante limplementazione effettiva del servizio come per esempio il controllo degli argomenti per lo scambio di informazioni;
un tipico errore il buffer overflow che permette in alcune circostanze lesecuzione di codice sul server remoto. Attenzione va data anche allaggiornamento continuo e tempestivo del web server e dellapplication server con i rispettivi aggiornamenti e patches disponibili. Infine importante adottare un sistema di firewall in grado di proteggere i servizi web ed evitare attacchi rivolti alle vulnerabilit dei protocolli. 42 7 Examples The following examples introduce code pieces for WebIdentity integration, for authentication and for encryption in a web-based application. The examples are written in VBScripts for ASP on the server side and in Javascipt and HTML on the client side; for use it is necessary to have IIS and the properly-configured Access driver on the server side whilst for the client side it is necessary to have Microsoft Internet Explorer. In the following examples some values stored in the session variables and in the application variables are used:
Session("SessionString") Session("user_PIN") Application("wi_Label") Application("wi_Password") Value of Random Session String that is initialized where requested inside the ASP pages:
Session("SessionString") =
WIDS.InitRndSessionString ( true, Session.SessionID,
"FREE-STRING" ) Value of User-Id stored in the authentication phase for use inside the http session. Variable declared in global.asa and initialized by taking the value from the database. It is used for identifying the token, which is service-related and therefore unique for the whole application. It is Server Secret, used for security management; this variable is declared in global.asa , the value of which is taken from the database. For storing the information an Access database is used with a User table containing the user's personal data (PIN, Name, ...) 7.1 Authentication This example clarifies the ASP pages that are necessary for using WebIdentity for authentication purposes. The authentication process follows the challenge/response sequence introduced in section 5.4 and is implemented with the aid of two ASP pages:
The former page is used as a response to the client authentication request and is useful for generating the challenge on the server side and a form necessary for the authentication request by the user, for using the token for response generation and for sending the response to the server. The latter page is used for effectively controlling the authentication by interpreting the response sent by the client by verifying the User-Id validity. The next page generates one form and the challenge that is necessary to the user for fulfilling recognition. First thing it generates the challenge univocally with the aid of the server ActiveX and then it created the form to send to the client, containing the challenge and the scripts that are necessary for querying the token for response generation. The index.asp page is implemented in HTML with Javascripts for execution on the client side and VBScripts for execution of the server side. 43 1
2
Dim WIDS Set WIDS = Server.CreateObject("WISrv.WebIdSrv") Session("SessionString") = WIDS.InitRndSessionString(1, Session.SessionID,
"AeCdEfGhIlMnOpQrStUvZ") Set WIDS = Nothing
<html>
<head>
<title>User Data</title>
</head>
<body>
3
<object classid="clsid:878A0D61-48D2-11D3-A75D-00A0245382DE" id="WIDC"
codebase="software/WICli.cab#version=4,0,0,0" VIEWASTEXT>
<embed type="application/x-wicli-plugin" name="WIDC" width="1" height="1"
hidden="true">
</object>
<script language="JavaScript">
4
function SendPIN()
5
6
7
8
9
10
document.WIDC.RndSessionString =
"<%= Session("SessionString") %>"
document.WIDC.Label = "<%= Application("wi_Label") %>"
document.WebIdData.PIN.value = document.WIDC.ReadPin();
document.WebIdData.submit();
</script>
<form action="login.asp" method="POST" name="WebIdData" >
<p>Site Entry</p><br>
<input type="button" language="javascript"
onclick="return SendPIN()" value="Enter">
<input type="hidden" name="PIN">
</form>
</body></html>
1. Creation of ActiveX WebIdentity Server object necessary for the univocal generation of the challenge. 2. Generation of the Random Session String dependent on time (with true as first parameter, the time value is used as one of the components for the generation of the Random Session String), on the session id
(Session.SessionID being the variable provided by ASP for identifying the session) as second parameter and 44 on an option string as third parameter. The Random Session String is stored in the session variable Session("SessionString") for being used in the client response check. 3. Request of the WebIdentity Client ActiveX object; the OBJECT tag enables inserting in the HTML document the ActiveX univocally identified by means of the class id, which for the client ActiveX is 878A0D61-
48D2-11D3-A75D-00A0245382DE. The ID attribute identifies the object univocally inside the document by means of a label thus enabling interaction. The CODEBASE attribute is necessary in case ActiveX is not present on the client. Such an attribute specifies the location (URL) from which the ActiveX is downloaded automatically. In addition to the URL it is possible to enter the control version ( #version= ) so that it can be downloaded, if more recent than the installed version. The EMBED tag enables inserting in the HTML document the client WebIdentity Plug-In univocally identified with the TYPE application/x-wicli-
plugin tag. 4. SendPIN function used during the submit phase for reading the User-Id from the token and for sending the response to the web server. 5. 6. Initialization of the WebIdentity client object with the Random Session String generated and sent by the server; the entry RndSessionString is a variable of the client ActiveX inside the HTML document; the Session("SessionString") entry is interpreted by the sever side and then replaced with a Random Session String. Initialization of the WebIdentity client object with the Label for token identification; the Label entry is a client ActiveX variable inside the HTML document; the entry Aplication("wi_Label") is interpreted by the server side and then replaced with the label chosen for the service. 7. Call of ReadPin method by the client ActiveX inside the HTML document for reading the encrypted User-Id form the WebIdentity token; the value of the User-Id is assigned to the PIN variable contained in the WebIdData Form inside the HTML document. The ReadPin is the function that generates the response to send to the server. 8. Explicit call to the submit of the WebIdData form for actual sending to the web server via a POST of the PIN variable containing the response. 9. Button inside the HTML document for authentication request by the user after inserting the WebIdentity token. 10. Variable hidden inside the HTML document used for storing the encrypted User-Id to send to the web server. 45 The following page manages the necessary operations for user verification and authentication; first thing it verifies the validity of the response sent by the client and extracts the User-Id; then it control the presence of the User-Id inside the local database for reading the profile of the token-related user. The connection between the user profile and the token is carried out with the User-Id returned by the client and the User-Id stored in the database. If the user turns out to be valid the control is entrusted with the actual home page of the service; otherwise the previous authentication page is re-
proposed. The ASP (login.asp) page is written in VBScript with the aid of ADO for interfacing with the Access database. 1
2
3
4
5
Dim WIDS Set WIDS = Server.CreateObject("WISrv.WebIdSrv") WIDS.Password = Application("wi_Password") WIDS.RndSessionString = Session("SessionString") WIDS.DecryptPIN( Request.Form("PIN") ) If WIDS.GetLastError() <> 0 Then Response.Redirect "index.asp"
Response.End End If Dim rsUser, sqlUser, fOk Set rsUser = CreateObject("ADODB.Recordset") sqlUser = "SELECT * FROM User WHERE User.PIN = '" &
Server.HTMLEncode(WIDS.pin) & "'"
6
rsUser.Open sqlUser, Application("Users_ConnectionString") if Not rsUser.eof Then Session("user_PIN") = WIDS.pin fOk = 1 Else fOk = 0 End if rsUser.Close Set rsUser= Nothing Set WIDS = Nothing If fOk=1 Then Server.Transfer "main.asp"
Else Response.Redirect "index.asp"
End If
1. Creation of the Server WebIdentity ActiveX object that is necessary for response verification and interpretation. 2. Initialization of the server object with the Server Secret; the Password entry is a server ActiveX variable inside the ASP page; the Application("wi_Password") entry is an application variable maintained by ASP, where the Server Secret value has been previously stored. 46 3. Initialization of the server object with the Random Session String; the same string previously communicated to the client; the entry RndSessionString is a variable of the server ActiveX; the Session("SessionString") stores the previously generated Random Session String. 4. Call of DecryptPIN method of the server ActiveX for decrypting the response sent by the client and retrieved by the call to Request.Form("PIN") which returns the corresponding value of the PIN variable of the HTML form. The User-Id is stored in the PIN variable of the server ActiveX. 5. Verification of the User-Id read operation; if the result is 0 it means that the client is in possession of a token properly initialized by the same service. 6. The previous control has verified the token validity; to verify the user status (user profile) a token-user connection has been created in the user information file in the local database. The research in the received User-Id local database enables associating the user with his/her profile and his/her current status. In this case if the user proves registered in the database he/she can be authenticated, otherwise he/she is readdressed to the login page.
Dim Name, rsUser, sqlUser Set rsUser = CreateObject("ADODB.Recordset") sqlUser = "SELECT * FROM User WHERE User.PIN = '" &
Server.HTMLEncode( Session("user_PIN") ) & "'"
rsUser.Open sqlUser, Application("Users_ConnectionString") if rsUser.eof Then Response.Redirect "index.asp"
Response.End End If Name = rsUser("Name") rsUser.Close Set rsUser= Nothing Dim WIDS Set WIDS = Server.CreateObject("WISrv.WebIdSrv") Session("SessionString") = WIDS.InitRndSessionString(1, Session.SessionID,
"AeCdEfGhIlMnOpQrStUvZ") WIDS.pin = Session("user_PIN") WIDS.RndSessionString = Session("SessionString") WIDS.password = Application("wi_Password") Dim CryptName CryptName = WIDS.Crypt( Name ) Set WIDS = Nothing
47 7.2 Cryptography The following example shows the use of WebIdentity for data encryption both by the server to the client and vice versa. WebIdentity is used for encrypting the Name information (containing the name associated to the user retrieved from the User table of the database) both when it is passed by the server to the client for display and when the client passes it to the server for modification. The application retrieves the requested content from the local database, in this case the Name field associated with the user, and encrypts it by using the WebIdentity server ActiveX object with an expressly-
initialized Session Random String. Hereunder the HTML page is generated; it contains the requested form with the encrypted datum and a series of Javascripts for proper running. While running the HTML page on the client browser the Javascripts OnLoad_Populate() function is automatically executed; with the aid of the client ActiveX is decrypts the information passed by the server and enters the decrypted value in the special field. During field modification by the user and during the request for modification transfer to the server the OnSubmit() Javascripts function is called for encrypting the data to send and carrying on with transfer. The encrypted data arrives to the server which decrypts it and enters it in the local database. The web page, prearranged for sending confidential information to the client, is represented by the following listing
(userdata.asp):
1
2
3
4
5
6
e 7
48
<html>
<head>
<title>User Data</title>
</head>
<object classid="clsid:878A0D61-48D2-11D3-A75D-00A0245382DE" id="WIDC"
codebase="software/WICli.cab#version=4,0,0,0" VIEWASTEXT>
<embed type="application/x-wicli-plugin" name="WIDC" width="1" height="1"
hidden="true"></object>
<script language="JavaScript">
function OnLoad_Populate()
var Name document.WIDC.RndSessionString = "<% = Session("SessionString") %>";
document.WIDC.Label = "<% = Application("wi_Label") %>";
Name = document.WIDC.Decrypt( "<%= CryptName %>" );
document.WebIdData.Name.value = Name;
function OnSubmit()
var Name document.WIDC.RndSessionString = "<% = Session("SessionString") %>";
document.WIDC.Label = "<% = Application("wi_Label") %>";
Name = document.WebIdData.Name.value;
document.WebIdData.Name.value = document.WIDC.Crypt(Name);
document.WebIdData.submit();
</script>
8
9
<body onload="OnLoad_Populate()">
10
11
12
13
14
15
16
17
18
<form action="changeuserdata.asp" method="POST" name="WebIdData" >
<p>Name:</p>
<INPUT TYPE="text" NAME="Name">
<INPUT TYPE="button" VALUE="Confirm" ONCLICK="return OnSubmit()">
</form>
</body></html>
49 1. The Name datum to pass to the client is retrieved from the local database User table; the User-Id is used that was retrieved and stored in the Session("user_PIN") session variable during authentication for retrieving the user profile. 2. Creation of the ActiveX WebIdentity Server object necessary for encrypting the data to send. 3. Generation of the Random Session String dependent on time (with true as first parameter, the time value is used as one of the components for the generation of the Random Session String), on the session id
(Session.SessionID being the variable provided by ASP for identifying the session) as second parameter and on an option string as third parameter. The Random Session String is also stored in the session variable Session ("SessionString") for being used for decrypting the information sent by the client. 4. 5. 6. Initialization of WebIdentity server object with the User-Id transmitted during authentication by the client and stored in the session variable Session("user_PIN"); the entry Pin is an ActiveX server variable. Initialization of the server object with the Random Session String; the entry RndSessionString is a variable of the server ActiveX; the Session("SessionString") entry stores the previously generated Random Session String. Initialization of the server object with the Server Secret; the Password entry is a server ActiveX variable inside the ASP page; the Application("wi_Password") entry is an application variable maintained by ASP, where the Server Secret value has been previously stored. 7. Call of the Crypt method of the server ActiveX for encrypting the data to send to the client (Name). The encrypted value is stored in the vbscript variable CryptName to be transmitted to the client. 8. Request of the ActiveX WebIdentity Client object; the OBJECT tag enables inserting in the HTML document the ActiveX univocally identified by means of the class id, which for the ActiveX client is 878A0D61-48D2-11D3-A75D-00A0245382DE. The ID attribute identifies the object univocally inside the document by means of a label, thus enabling interaction. The CODEBASE attribute is necessary in case ActiveX is not present on the client. Such an attribute specifies the location (URL) from which the control is downloaded automatically. In addition to the URL it is possible to enter the control version (
#version= ) so that it can be downloaded, if more recent than the installed version. The EMBED tag enables inserting in the HTML document the client WebIdentity Plug-In univocally identified with the TYPE application/x-wicli-plugin tag. 9. OnLoad_Populate function used in the form generation phase for initializing the content fields sent by the server in encrypted format; the function sees to decrypting the data sent by the server and to setting the Name field with the corresponding value. 10. Initialization of the WebIdentity client object with the Random Session String generated and forwarded by the server; the entry RndSessionString is a variable of the client ActiveX inside the HTML document; the Session("SessionString") entry is interpreted by the sever side and then replaced with a Random Session String. 11. Initialization of the client object with the token identification Label; the Label entry is a client ActiveX variable inside the HTML document; the entry Aplication("wi_Label")is interpreted by the server side and then replaced with the label chosen for the service. 12. Call of the Decrypt method of the client ActiveX for decrypting the data sent by the server (Name). 13. Setting of variable in the form with the user name in plain text. 14. OnSubmit function used during modification of the name value for transmission to the server. 15. Initialization of the client object with the Random Session String generated and sent by the server; the entry RndSessionString is a variable of the client ActiveX inside the HTML document; the Session("SessionString") entry is interpreted by the sever side and then replaced with the Random Session String string. 50 16. Initialization of the client object with the token identification Label; the Label entry is a client ActiveX variable inside the HTML document; the entry Aplication("wi_Label") is interpreted by the server side and then replaced with the label chosen for the service. 17. Call of the Crypt method of the client ActiveX for encrypting the data to send to the client (Name). The encrypted value is stored in the Name variable of the WebIdData form. 18. Explicit call to the form submit for sending the encrypted Name variable to the web server with POST. The web page, prearranged for receiving the encrypted information by the client, is represented by the following listing
(changeuserdata.asp):
1
2
3
4
5
Dim WIDS Set WIDS = Server.CreateObject("WISrv.WebIdSrv") WIDS.pin = Session("user_PIN") WIDS.RndSessionString = Session("SessionString") WIDS.password = Application("wi_Password") Dim Name Name = WIDS.Decrypt( Request.Form("Name") ) Dim objConn, strSQL Set objConn = Server.CreateObject("ADODB.Connection") objConn.Open Application("Users_ConnectionString") strSQL = "UPDATE User SET Name='" & Name & "' WHERE User.PIN = '" &
Server.HTMLEncode(WIDS.pin) & "'"
6
objConn.Execute strSQL objConn.Close Set objConn = Nothing Set WIDS = Nothing
<html>
<head>
<title>User Data</title>
</head>
<body>
<p>OK</p>
</body></html>
51 1. Creation of the ActiveX WebIdentity Server object necessary for decrypting the information transmitted by the client. 2. 3. 4. Initialization of WebIdentity server object with the User-Id transmitted during authentication by the client and stored in the session variable Session("user_PIN"); the entry Pin is an ActiveX server variable. Initialization of the server object with the Random Session String; the RndSessionString entry is an ActiveX server variable; the Session("SessionString")entry stores the previously generated Random Session String which is identical to the string passed to the client for encrypting the information. Initialization of the server object with the Server Secret; the Password entry is a server ActiveX variable inside the ASP page; the Application("wi_Password") entry is an application variable maintained by ASP, where the Server Secret value has been previously stored. 5. Call of the Decrypt method of the server ActiveX for decrypting the data sent by the client (Name). 6. Storage of the value in the Name field of the User table in the local database. 52 8 Appendixes 8.1 Symmetric cryptography Symmetric algorithms use a single numeric key used both for encrypting and decrypting data. A secure message is encrypted for the receiver by using a key that is known only to the sender and the receiver. The principle on which the algorithm is based is that by encrypting a plain text with a certain key and by decrypting the encrypted text with the same key it is possible to obtain the same plain text again (see figure 8.1). Dk(Ek(Pk)) = P Where:
P = plain text E = encrypting operation D = decrypting operation K = key Message Encryption Ciphertext Dencryption Original Message Figure 8.1 Operating layout of a symmetric algorithm The most common symmetric algorithms are AES, CAST, DES, 3DES, RC2, RC4, RC5, IDEA, Blowfish. 8.2 AES The Advanced Encryption Standard (AES), is a block encryption algorithm used as standard by the USA government AES is the implementation of a more general algorithm known as Rijndael. AES can have 128, 192, or 256 bit encryption keys. WebIdentity uses 256 bit encryption. To date is is considered an extremely secure algorithm and it can be estimated that it will be used successfully all over the world as it happened to its predecessor, the Data Encryption Standard (DES). See [AES197] or:
http://en.wikipedia.org/wiki/Advanced_Encryption_Standard http://it.wikipedia.org/wiki/Advanced_Encryption_Standard 53 8.3 DES The Data Encryption Standard (DES) is an encryption algorithm chose as standard by the Federal Information Processing Standard (FIPS) for the USA government in 1976 and then adopted worldwide. DES is reckoned to be insecure for a number of applications. Its insecurity derives from the key used for encrypting the messages, which is only 56 bit. http://en.wikipedia.org/wiki/Data_Encryption_Standard http://it.wikipedia.org/wiki/Data_Encryption_Standard 8.4 Triple DES Triple DES is a block encryption system based on the repetition of \ref DES for three times. Triple DES was introduced for making the DES secure. This algorithm expands the key by preventing a brute force attack even if it makes the algorithm virtually vulnerable to attacks, which are not feasible in practice. Triple DES 2EDE is made up of a 128 bit key (only 112 bits are useful) where the encrypted data is obtained by applying the DES with the first 56 bits of the key, then decryption is applied with the second part of the key, and finally a new encrypting is carried out with the first part of the key. 8.5 Hashing algorithms By hash functions those functions generally defined as one-way hash function are meant; hereunder a definition is provided. Suppose that M is an arbitrary length message and h a fixed length binary string. The one way hash function H function is defined as follows:
h = H(M) Besides, for H it is true:
1. Given M, it is easy to calculate h. 2. Given h, it is difficult to calculate M so that H(M) = h. 3. Given M, it is difficult to find another M message so that H(M) = H(M). In many applications the following property is also required:
4. it is difficult to find two such M and M messages that H(M) = H(M). By easy a calculation that any computer can carry out in an extremely short time is meant, whilst by difficult a calculation that it is impossible to carry out in reasonable time is meant at the state-of-the-art (in terms of days, weeks, months) even with the aid of exceptionally powerful computation resources. Points 1 and 2 of the above-given definition identify the unidirectional characteristic (one way) required to Hash algorithms: given an x value it is easy to calculate f(x), but given f(x) it is difficult to extract x from a computational point of view. Point 3 states the collisions are improbable, that is, difficult. It is understood as computationally impossible for the same hashing value to correspond to two different values. Given an x and y value so that x is different from y then the x ( f(x) ) hashing value will be different from the y ( f(y) ) hashing value. The value obtained from a hashing algorithm is called message digest. 54 Message HASH Message Digest Figure 8.2 Operating layout of hash algorithms Examples of hashing algorithm are SHA-1, MD2, MD4, MD5. 8.6 Glossary User-Id PIN Label User identity dependent on the key personal data ad univocal data. Alternative name for indicating the User-Id. Please refer to the User-Id definition. Identifier assigned to each service that is necessary for identifying the token on the bus. Server Secret Server secret that allows secure operations. Password Server Alternative name for indicating the Server Secret. See the definition of Server Secret. password Challenge Response Hash Alternative name for indicating the Server Secret. See the definition of Server Secret. Random Session String; the most univocal string possible used for generating authentications that are always univocal and unforeseeable. Response that the client processes following an authentication attempt. Function describer in the appendix Errore. L'origine riferimento non stata trovata.. Sync Number Synchronization number used in the write remote operation. 8.7 Bibliography
[AES197]
Announcing the ADVANCED ENCRYPTION STANDARD - AES FIPS PUB 197, November 2001.
[RFC1319]
B. Kaliski, The MD2 Message-Digest Algorithm, Request for Comment 1319, April 1992.
[RFC1320]
R. Rivest, The MD4 _Message-Digest Algorithm, Request for Comment 1320, April 1992.
[RFC1321]
R. Rivest, The MD5 _Message-Digest Algorithm, Request for Comment 1321, April 1992.
[FLAN98]
D. Flanagan, JavaScript The Definitive Guide - Third Edition, OREILLY, June 1998.
[BASP99]
[PASP99]
D. Bruser, J. Kauffman, J. T.Llibre, B. Francis, D. Sussman, C. Ullman, J. Duckett, Beginning Active Server Pages 3.0, Wrox Press Ltd., 1999 A. Homer, D. Sussman, B. Francis, D. Esposito, A. Chiarelli, S. Robinson, R. Anderson, G. Reilly, C. McQueen, C. Blexrud, D. Denault, J. Schenken, B. Kropog, D. Sonderegger, M. Gibbs, Professional Active Server Pages 3.0, Wrox Press Ltd., 1999
[SCH96]
B. Schneier, Applied Cryptography, Protocols, Algorithms and Source Code in C, Second Edition, Iohn Wiley & Sons Inc., 1996.
[SMIT97]
R. E. Smith, Internet Cryptography, Addison-Wesley, 1997. 55
| frequency | equipment class | purpose | ||
|---|---|---|---|---|
| 1 | 2007-11-28 | JBP - Part 15 Class B Computing Device Peripheral | Original Equipment |
| app s | Applicant Information | |||||
|---|---|---|---|---|---|---|
| 1 | Effective |
2007-11-28
|
||||
| 1 | Applicant's complete, legal business name |
EUTRONSEC S.p.A.
|
||||
| 1 | FCC Registration Number (FRN) |
0013668538
|
||||
| 1 | Physical Address |
Via Gandhi,12
|
||||
| 1 |
Treviolo, N/A 24048
|
|||||
| 1 |
Italy
|
|||||
| app s | TCB Information | |||||
| 1 | TCB Application Email Address |
k******@emcc.de
|
||||
| 1 | TCB Scope |
A1: Low Power Transmitters below 1 GHz (except Spread Spectrum), Unintentional Radiators, EAS (Part 11) & Consumer ISM devices
|
||||
| app s | FCC ID | |||||
| 1 | Grantee Code |
TFC
|
||||
| 1 | Equipment Product Code |
AAL
|
||||
| app s | Person at the applicant's address to receive grant or for contact | |||||
| 1 | Name |
R******** G****
|
||||
| 1 | Telephone Number |
+39 0********
|
||||
| 1 | Fax Number |
+39 0********
|
||||
| 1 |
r******@eutronsec.it
|
|||||
| app s | Technical Contact | |||||
| n/a | ||||||
| app s | Non Technical Contact | |||||
| n/a | ||||||
| app s | Confidentiality (long or short term) | |||||
| 1 | Does this application include a request for confidentiality for any portion(s) of the data contained in this application pursuant to 47 CFR § 0.459 of the Commission Rules?: | Yes | ||||
| 1 | Long-Term Confidentiality Does this application include a request for confidentiality for any portion(s) of the data contained in this application pursuant to 47 CFR § 0.459 of the Commission Rules?: | No | ||||
| if no date is supplied, the release date will be set to 45 calendar days past the date of grant. | ||||||
| app s | Cognitive Radio & Software Defined Radio, Class, etc | |||||
| 1 | Is this application for software defined/cognitive radio authorization? | No | ||||
| 1 | Equipment Class | JBP - Part 15 Class B Computing Device Peripheral | ||||
| 1 | Description of product as it is marketed: (NOTE: This text will appear below the equipment class on the grant) | USB Webidentity | ||||
| 1 | Related OET KnowledgeDataBase Inquiry: Is there a KDB inquiry associated with this application? | No | ||||
| 1 | Modular Equipment Type | Does not apply | ||||
| 1 | Purpose / Application is for | Original Equipment | ||||
| 1 | Composite Equipment: Is the equipment in this application a composite device subject to an additional equipment authorization? | No | ||||
| 1 | Related Equipment: Is the equipment in this application part of a system that operates with, or is marketed with, another device that requires an equipment authorization? | No | ||||
| 1 | Is there an equipment authorization waiver associated with this application? | No | ||||
| 1 | If there is an equipment authorization waiver associated with this application, has the associated waiver been approved and all information uploaded? | No | ||||
| app s | Test Firm Name and Contact Information | |||||
| 1 | Firm Name |
Prima Ricerca & Sviluppo S.r.l.
|
||||
| 1 | Name |
E******** B******
|
||||
| 1 | Telephone Number |
39-03********
|
||||
| 1 | Fax Number |
39-03********
|
||||
| 1 |
e******@primaricerca.it
|
|||||
| Equipment Specifications | |||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Line | Rule Parts | Grant Notes | Lower Frequency | Upper Frequency | Power Output | Tolerance | Emission Designator | Microprocessor Number | |||||||||||||||||||||||||||||||||
| 1 | 1 | 15B | |||||||||||||||||||||||||||||||||||||||
some individual PII (Personally Identifiable Information) available on the public forms may be redacted, original source may include additional details
This product uses the FCC Data API but is not endorsed or certified by the FCC