To: ForYourEyesOnly who wrote (254 ) 3/18/1998 1:23:00 PM From: Justin Franks Read Replies (1) | Respond to of 1242
Continued....... More white papers: 3. Diversinet -- The Product Line Diversinet's products can be software-based or can use hardware smart cards for authenticating users. The technology can also be applied to devices that need to communicate and authenticate each other in a networked environment. 3.1. The Diversinet Certificate Server At the core of the Diversinet product line is a Certificate Server that issues on-demand certificates that serve as the basis for authenticating users to the system. In addition to being compatible with the X.509 standard v3 format, 'Certificates' include customizable extensions. The Certificate Server (CS) issues certificates and distributes public keys in an anonymous and trusted manner. A unique ID, stored in the "name field" of the user's certificate, is assigned to each user. The Diversinet CS then records the ID and public key in the systems database(s). Any interested system user can, just by knowing a user's ID, retrieve that users certificate and hence his or her public key. Unlike existing systems, where the certificates include additional personal information that might be irrelevant to the certification process (e.g. user's name, address or phone number), Diversinet's certificates only include the user's numerical ID. This is an important feature to many users such as financial institutions. It is not necessary to include the customer's name in the communication between the customer and the financial institution. The benefits include better customer privacy and protection of the financial institution's customer list. Furthermore, an advantage of including only relevant information is that the Diversinet certificates have a small footprint. This reduces processing time and storage requirements, making it more efficient and significantly less expensive to encode on a smart card. At the center of the Certificate system is a Master Certificate Server (MCS). The MCS acts as the ultimate signing authority within the system and has a public key that is known to everyone within the system. The MCS has no direct communication link with any end users. A user only knows the MCS by the widely held public key. In addition, Diversinet has developed a technology to protect the system in the event that the MCS private key is compromised. This will not only ensure that the system remains secure but also allows the MCS public key to be updated in a secure manner. The diagram below describes the process through which a user requests a certificate. After downloading the Diversinet client software, the user generates a pair of keys, both private and public, and protects the private key with a password. The user then sends the public key and a password (used for future changes with the Certificate Server) to the Certificate Server encrypted with the Certificate Server's public key. Once received and registered by the Certificate Server, a Certificate with a unique ID is generated and sent back to the client. In addition, that Certificate includes the user's public key, certificate chain and any necessary extension fields. When a user requests another user's or entity's certificate, the request is submitted to a CS and a certificate chain is returned. The chain provides the requesting user/entity with all the certificates up to the MCS public key, which serves as a root key that is trusted within the network. 3.2. The Certificate The Certificate contains the credentials for the users to be authenticated to the network (system). The Diversinet authentication servers use the Certificate to ensure the user's possession of a private key. The basic Certificate provides authentication without verifying other user information present within the network. For example, a bank customer's personal information is stored in the bank's database. However, for the purpose of withdrawing cash, it is not necessary to check the user's address. The only security issue is whether that customer is authorized to make the requested transaction. The Certificate ID confirms the user's authenticity and his/her authorization to perform a specific function (Note that authorization can be verified using Permits described in the next section). This feature of the Diversinet system means that there is no need to reissue a Certificate each time a customer moves or changes a phone number. It also increases processing speed within the system. The Certificate also protects the user's privacy since it does not include unnecessary personal information, simply the user's ID. 3.3. Light-weight Authentication The Diversinet Light-weight authentication system consists of the authentication server that works in tandem with an enterprise web server to provide lightweight, high-security authentication for users and a client authentication system that provides the users with the connectivity to the Diversinet servers. 3.4. The Permit System The Permit system is an extension of the Authentication Server. The Server holds the Permits that are issued to the system users giving them authorization to access specific resources. The access could be limited either by time, number of accesses or by any other application-dependent parameter. 3.5. Permits The Diversinet Permit Server provides users with Permits, which are authorizations for users to access certain resources within the network. The combination of a Certificate and a Permit authenticates a user and verifies that that user is authorized to conduct a particular type of transaction within the networked application. The Permits can be a single-time access credential or allow access within a certain time frame or any other criteria the customer chooses. The Permit offers a real-time authorization scheme where the server can automatically identify the capabilities that a user has without the need to connect to other servers on the network. A user can have several Permits, each allowing the user access to a specific application. Permits can be cancelled by deleting them from the server or marking them as invalid. 3.6. Diversinet - The Technology Advantages Diversinet technology offers significant advantages: Anonymity: the globally unique ID does not disclose the user's identity. There is no need to identify the personal attributes of the ID holder or the identity of the requester of a certificate. Small Footprint Certificate: the Certificate is smaller than current implementations in the industry which makes it most suitable for smart cards or other applications with size limitations. Trust: any user need only trust the Master Certificate Server. Every user knows the public key of the MCS and all information received is ultimately validated by that key. Distributed: the Certificate Server does not require a user to communicate with any particular Diversinet CS. The user can request an ID from any Diversinet CS within the system and have it returned. The Diversinet CS finds the certificate where it exists within the system. Scalable: there is no theoretical limit to the number of certificates a system can issue and manage. No Revocation: In current implementations of PKIs, certificates have to be revoked in two cases. First case occurs if an entry in the certificate, such as the owner's address, changes. Second case occurs when the private key associated with the certificate is compromised. With the Diversinet solution certificates are not revoked, eliminating the need to manage a certificate revocation list, a none trivial task, since at any time a fresh certificate can be retrieved from the server. Any retrieval of a user certificate would include the user's most recent public key in case the previous one was compromised. Root Key Rollover: the system provides a safe method for changing the root key of the MCS when necessary. It is essential for any system using public-key technology to profile this feature as a built-in component so that the system does not require a long down time while keys are being updated. Flexible Cryptography: the Diversinet CS is designed to make use of many different cryptographic technologies. The Certificate Server is currently able to use RSA and ECC (Elliptic Curve Cryptography). 4. Diversinet -- The Applications 4.1. Network Authentication Systems using Public-Key Certificates Customers will be able to install and deploy authentication systems within their networks with users immediately known to the system. Any Permit presented by an authenticated user is locally checked for validity and the user is then granted access to the resource required without connecting to other nodes in the network. Since each Certificate is regenerated with each request, the system is guaranteed to provide a fresh (non-revoked) certificate. This eliminates the overhead and administration associated with revocation such as maintaining a CRL (Certificate Revocation List). 4.2. Lightweight Permit systems for restricted-use and pay-per-use systems The Permit systems based on Diversinet's Permit technology provide customers with a versatile, lightweight mechanism to the very difficult access control problem. The Permit servers issue and track the use of the Permits allowing users to get exactly the access they are entitled to whether it is a resource or performing a transaction. 4.3. Inexpensive Smart Card Solutions for Networked Applications The small size of the Certificate makes a smart card solution based on the Diversinet technology very appealing. Customers can now use sophisticated and cryptography-enabled smart cards for any application that requires authentication. A smart card can include the user's private and public keys for cryptographic operation, while the certificates themselves are obtained and checked for validity from the Certificate servers in the network. 4.4. Embedded Authentication and Network Devices The Diversinet technology allows for the network devices such as the routers existing in a network to function as the Certificate and the Authentication servers. Vendors of such network devices can enhance the functionality of their routers by providing higher level functions such as user authentication and verification of the user's access rights. This is possible because Permits include all the information needed to verify the authenticity of a user's access rights. 4.5. Wireless Systems As the 20th century is nearing its end more and more of humankind are relying on electronic gadgets from cell phones and pagers to palm computers to perform business tasks. As such use becomes widespread authentication of such devices and entities is becoming a requirement. Diversinet's small footprint Certificate makes it a perfect solution to be included in any wireless systems where information is exchanged between devices. 5. Diversinet -- An Application Example 5.1. An Extranet for a Corporation's Suppliers and Internal Departments A Corporation, code-named Advanced Technology Inc. (ATI) has implemented an Extranet that will allow qualified and pre-approved parts suppliers to receive purchase orders from authorized departments within the cooperation. While designing the application headquarters required that it not have to repeatedly approve purchase orders. The head office wanted to pre-approve divisions for a pre-determined purchase order amount. The Diversinet technology was a perfect fit for this application. Below is a description of how ATI used the Diversinet technology to build the application code-named EasyPurchase. All parties, including headquarters, every department and pre-approved supplier, involved in the planned transactions apply for a Certificate from a CA in the Diversinet Authentication system. In addition each department receives a Permit that specifies what it is authorized to purchase (maximum amount in dollars). Suppliers need not view the amount that each department is authorized to purchase in each transaction hence the advantage of separating the permit from the certificate. The EasyPurchase application validates the purchase order by checking the appropriate permit before submitting it to a supplier. Headquarters gives Engineering the authority to qualify suppliers and Manufacturing to purchase from those suppliers. This authority is given as part of each department's Certificate. Once authorized, the engineering department pre-qualifies suppliers. Each approved supplier than applies for a Certificate that would be used for authentication. Also each submits a request for a Permit(s) that determines what they can sell to ATI divisions and for how long. One of the requirements was to have suppliers approved for an initial probation period. Once the company was satisfied with the quality of parts the supplier would be approved for a year. Suppliers are also subject to periodic re-qualification. Permits were a perfect fit for this requirement. A Permit would be issued for the probation period. Once the supplier is cleared a new Permit is issued by the ATI system. Headquarters required that the plants placing the orders would never have to view the Permit issued to the supplier. The Permit is part of the application and is validated by the application as needed. Let's assume that the purchasing plant is located in New York and has been authorized by headquarters of ATI to purchase chips for one of the pre-qualified suppliers, in particular, ChipsInc. The plant in New York contacts ChipsInc and they authenticate one another, to their mutual satisfaction, using the issued Certificates. The New York plant completes the purchase order. Before sending it off to ChipsInc, the EasyPurchase application (using Diversinet system) verifies that the order is valid (purchase value does not exceed allowed maximum) i.e. does not contradict the resource entry in the Permit issued for the New York plant. ChipsInc receives the order and executes it. Once the certificates are issued and the Permits are defined headquarters does not have to interfere any more in the described transaction. Each supplier and department trusts the system without involving any third party centralized CA. In summary, the above system does not require a central transaction-clearing house. The transaction is securely made between the parties even though no previous communications was established between them. Finally there is no requirement for external verification of either. ATI remained in complete control of the entire process.