A SECURITY SYSTEM FOR METEOR WORKFLOW
MANAGEMENT SYSTEM
by
MEI FAN
This project is part of Workflow Management System project under the development in Large Scale Distributed Information Systems (LSDIS) laboratory. It is partially supported by the NIST Advanced Technology (under the HIIT contract, number 70NANB5H1011) in partnership with Healthcare Open Systems and Trials (HOST) consortium. I would like to thank my major advisor, Dr. John A. Miller, for his support and guidance. He has been a constant source of suggestions and help throughout this project. I would also like to express my gratitude to all the other people in the group, for all their suggestions and help.
Table of Contents
Acknowledgements *
1 Introduction *
1.1 Overview of Web-Based Workflow Management Systems (WfMSs) *
1.2 Description of This Project *
1.3 Organization of This Thesis *
2 Security Services and Technologies *
2.1 Cryptography *
2.2 Digital Signature *
2.3 Certificate *
2.4 Security Socket Layer (SSL) *
2.5 Role Based Access Control (RBAC) *
3 Security Services for Web-Based Workflow *
3.1 Authentication Service *
3.2 Access Control Service *
3.3 Data Confidentiality Service *
3.4 Data Integrity Service *
3.5 Non-Repudiation Service *
3.6 Web-Based Application Security and Java *
4 A Security Architecture for METEOR WfMSs and Its Implementation *
4.1 System Components *
4.2 Implementation Details *
4.3 Package View *
5 Example: A "Secured" Web-Based Workflow *
5.1 The Workflow Design *
5.2 The Role Design *
CHAPTER 1
Workflow is one of the important new technologies of today. The use of workflow is growing rapidly because of its ability to increase business productivity. It defines a set of activities and rules that combine to achieve an objective. Workflow technology involves creating a computer model of the flow of work, then controlling the distribution and flow of assignments and data by computer. Workflow systems promise better employee productivity by automating support for collaborative work between people. Web technology is becoming a viable choice for workflows that span multiple organizations and geographical areas. Web-based workflow potentially represents a major security risk. This chapter gives a brief introduction to web-based workflow, describes the risks associated with the web-based workflow system, and presents the organization of this thesis.
1.1 Overview of Web-Based Workflow Management Systems (WfMSs)
Workflow Management Systems (WfMSs) provide an automated framework for managing intra- and inter-enterprise business processes. According to the Workflow Management Coalition (WfMC), a Workflow Management System is a set of tools providing support for process definition, workflow enactment, and administration and monitoring of workflow processes [Hol94]. Application domains where workflow technology is currently in use include healthcare, education, telecommunications,
manufacturing, finance and banking and office automation. WfMSs are being used today to reengineer, streamline, automate and track organizational processes involving human and automated information systems [JAD94, GHS95, Fis95, SKM96, SGJ96]. The success of WfMSs has been driven by the need for businesses to stay technologically ahead of the ever-increasing competition in typically global markets.
Web technology is an appropriate choice for a workflow infrastructure for two distinct and important reasons. First, the ubiquitous nature of Web browsers makes them a natural user interface. Web browsers satisfy one of the primary concerns in application deployment - it allows users with any of the popular computing platforms to be able to participate in a workflow without any additional hardware. Second, Web technology provides a solid communications infrastructure for building WfMSs. For example, WebWork [Miller98] is a pure web-based WfMS and OrbWork [Kochut98] couples web technology with a web-oriented Common Object Request Broker Architecture (CORBA) such as OrbixWeb.
This project originated to provide security solutions for METEOR (Managing End-To-End OperRations) [KS95, SKM96], a workflow management system developed at the Large Scale Distributed Information System Lab. The solutions provided by this thesis can also generally apply to other workflow systems.
1.1.1 METEOR Model and Concepts
A workflow usually contains a set of automated and/or human tasks that are organized based on real world rules or business processes.
A task represents an abstraction of activities that can be performed by a variety of processing entities. For example, computer programs perform non-transactional tasks. Tasks performed by human are a special case of a non-transactional task. A transactional task is performed by a database transaction. All the tasks not performed by human are automatic tasks. A computer task may be a database transaction a search for a document across the Internet and so on. Human tasks are usually data-entry type tasks or the tasks with no automated equivalents exist, such as a doctor making a diagnosis. A workflow is considered a compound task that is a collection of sub tasks. A worklist is a list of to-do jobs.
A Scheduler coordinates control and data transfer between tasks. Tasks can communicate with each other through the Scheduler. Task Managers are used to control the execution of the tasks.
There are two main parts in the METEOR system: the build time and run time systems [Kochut99]. The build time system is response for defining the process. The workflow applications are designed using a graphical workflow designer (MTD), which includes a map designer, a data designer and a task designer. The map designer is used to specify the maps of a workflow. The data designer is used to create the data object manipulated by tasks in the workflow. The workflow definition is grammatically described using workflow intermediate language and stored in a specially formatted text file called WIL files. The automatic code generator then generates a workflow code for the designed workflow application from this file. But the code generator does not generate code for automatic tasks because such tasks are application specific. After a workflow is built, the run time system is in charge of running the workflow.
1.2 Description of This Project
There are many potential threats for web-based workflow. For example, not everyone is allowed to execute certain workflow task, not every one is allowed to access all information, we do not want information sent over the Net to be stolen, we do not want tampered information to be stored in a database. We need to identify the security issues related to workflow and find solutions. A lot of groups and companies working on the workflow management system are considering security issues, including Knowledge Based Systems, Inc. They are working on the Workflow-Enhanced Role-Based Authorization Control (WERBAC). JetForm's Workflow (2.0) provides data encryption capabilities for more secure workflows across networks.
In this thesis, we sort out some of the more promising security alternatives and organize them into a secure architecture suitable for web-based workflow. Three key aspects of security will be addressed in depth in this thesis, authentication, accession control and secure communication. Authentication is a prerequisite for proper access control. Secure communication makes stealing or tampering the messages sent across the Net practically impossible. A reference workflow prototype is developed using Java.
1.3 Organization of This Thesis
This thesis is organized as follows. Chapter 2 is a discussion of common security services and mechanisms. Chapter 3 describes security services needed for web-based workflow systems. At the end of chapter 3, Java's security model is discussed since Java, an execution platform born of the Net, has made distributed computing a practical reality and provides powerful and flexible security features for web-based workflow systems. Chapter 4 describes a secure architecture for web-based workflows and a prototype implementation of it. Chapter 5 presents a secured workflow example. Chapter 6 gives conclusions and explores some future work.
CHAPTER 2
Security Services and Technologies
The International Standards Organization (ISO) has specified five common security services that network-based information systems should provide [Opp98]:
Authentication services are to provide the ability to verify that an entity is the one it claimed to be. Access control services are to provide the protection of system resources against unauthorized use. Data confidentiality services are to provide the protection of data from unauthorized disclosure. Data integrity services are to provide the protection of data from unauthorized modifications. Non-repudiation services are to prevent one of the entities involved in an action from later denying participation in all or part of the action.
Authentication services are important because they are prerequisites for proper access control. A user or a process must be properly authenticated before an access control service can effectively mediate access to system resources. Data confidentiality services can protect information being stolen but it can not provide protection against the duplication or modification of data units. In this case, we need data integrity services.
Non-repudiation services are becoming important in the context of electronic commerce on the Internet.
Having set the goals to provide the above mentioned security services, let’s take a look at the technologies and solutions that currently exist in the computer industry [CGC95, RGR97 Oak98, Knu98].
Cryptography is a collection of techniques used to protect information sent over communication channels. It mainly includes encryption and decryption techniques as shown in the Figure 2.1.
Encryption is the transformation of data into some unreadable form. Its purpose is to ensure privacy by keeping the information hidden from anyone for whom it is not intended. Decryption is the reverse of encryption. It is the transformation of encrypted data back into some intelligible form.
There are two kinds of approaches: symmetric key algorithms and public key algorithms (asymmetric). When an algorithm uses the same key for both encryption and decryption, it is a symmetric key algorithm. When a pair of key is used, it is called a public key algorithm (asymmetric). One key is used for encryption and only the corresponding key can be used for decryption.
Symmetric key algorithms are used to encrypt the bulk of data since they are faster than the public key algorithms and easier to implement. But since two parties must have the same key, one must to make sure to send the key to the other party in a secure way after the key is generated. Typical symmetric key algorithms are DES, 3-DES, IDES, Blowfish, RC2, RC4, and RC5.
Figure 2.1 Cryptograph: Encryption and Decryption
Figure 2.2 Public Key Algorithm
Public Key Encryption involves the use of a "public/private key pair". In the Figure 2.2, E stands for the encryption algorithm and D stands for the decryption algorithm. Data is encrypted using B's public key and sent to B over the network. Upon receiving the encrypted data, B decrypts it using his/her private key to get the original data.
When the public key is used for encryption and the private key is used for decryption, the message is only meaningful to the designated recipient since only the entity having the private key will be able to decrypt the message. Sometimes, the private key is used for encryption, but under this scenario, we care more about who is the message sender instead of securing the message since anyone may have the sender's public key to decrypt the message. Digital signatures use public key algorithms under this scenario as shown below in Figure 2.3 (S stands for signing algorithm, and V stands for verifying the signature). Another difference between digital signatures and public key encryption is that the message sent over the Net under this scenario is not encrypted. We will discuss digital signatures in more detail later.
Figure 2.3 Digital Signature Algorithm
A significant advantage of public key algorithms is that private keys never need to be sent out over a network. Unfortunately, it is also more computationally expensive. Typical public key algorithms are Diffie-Hellman, RSA, ELGamal, and DSS.
A digital signature is a way of authentication that enables the receiver to verify the sender is whom he claims to be. Like handwriting signatures, digital signatures should satisfy several properties [Opp96]. It should be unforgeable—only one sender can attach his signature to a document, verifiable—a receiver must be able to verify it, non-deniable—the sender must not be able to repudiate it later. But, unlike handwriting signatures, digital signatures incorporate the data that are signed. A digital signature is not constant but a function of the data. So, it is unalterable—no one can change the document after it has been signed and it is non-reusable—one can not cut a signature off one document and attach it to another.
A certificate is a digitally signed statement from a certificate issuer, saying that the public key of some other entity (the subject) has some particular value. A certificate is like a driver’s license. It binds an entity’s public key to his name.
A typical certificate file includes the subject’s name, his public key, certificate issuer, the issuer’s digital signature, an expiration date and a serial number. If you trust the issuer, you trust that the association in the certificate between the specified public key and the subject is authentic.
Another term related to certificates is Certification Authority (CA). A CA is an entity (e.g., a business) that is trusted to sign (issue) certificates for other people (entities). There are many such Certification Authorities, such as VeriSign, GTE and Netscape.
2.4 Security Socket Layer (SSL)
SSL (3.0) is a program layer created by Netscape for managing the security of message transmissions in a network. It provides four security services: authentication, non-repudiation, data integrity and data confidentiality [GS97].
Authentication and non-repudiation of server and client is provided using public-key certificate exchange and digital signature. Data integrity is provided using message authentication code (MAC). Data confidentiality is provided using keys and encryption algorithm negotiated during SSL handshake.
SSL handshake protocol consists of two parts, server authentication and client authentication. The second part is optional. But for our workflow project, we need both of them.
According to [FKK96], when setting up a server, the administrator creates a key pair and gets a digitally signed certificate from a trusted Certification Authority.
After a client connects to a server, it sends a list of supported cryptographic algorithms. The server chooses one of them and sends back its selection together with the server’s certificate. The client can then retrieve the server’s public key from its certificate.
The client requests the server to prove its identity by sending a message encrypted using the server’s public key. The server deciphers it using its private key and sends a finish message to the client for his verification. Since only the server holds his private key, nobody but the server can decrypt the encrypted message and generate the expected finish message, the client is assured that the server is who it claimed to be.
Figure 2.4 SSL Protocol
Both the client and the server use the same hash function on the message the client first sent and convert it into a secret that is only known to the two sides. The secret is used to generate session keys for encryption and MAC computations.
Similarly, a client can authenticate himself to the server. It sends its certificate and a verify message which is its digital signature in response to the server’s request. So, the server can verify its digital signature.
The handshake procedure is not encrypted. The finish message is the first protected with the just-negotiated algorithm, key, and secrets.
After the handshake finishes, communication is encrypted with the selected algorithms and keys illustrated below. The bracket means "encrypted with".
[Application data, MAC] session key
Data integrity is checked every time.
2.5 Role Based Access Control (RBAC)
Security administration for large networked systems is costly and error-prone. With role based access control (RBAC) [BCF97] security is managed at a level that corresponds closely to the organization's structure. It is simplifies management of authorization while providing an opportunity for greater flexibility in specifying and enforcing enterprise-specific protection policies comparing to access control lists (ACLs), which is a common access control mechanism.
2.5.1 ACLs’s limitation
One of common access control mechanism is control user access to protected objects through the creation and maintenance of access control list (ACL). ACLs associate a protected object with a list of users or groups of users according to their respective modes of access to the protected object. ACLs have many advantages if the users are the owners of the protected object. Users have the right to grant other users access to the object. ACLs make it easy to know who has access to the object and under what access mode. But in the real world enterprises, end users are not the owner of the information. The corporation owns the information. Access priorities are controlled by the organization and are often based on employee functions rather than data ownership [Bark97].
Also, it is very difficult to retrieve the information about the access rights for a particular user under an ACL structure.
2.5.2 What is RBAC
The central notion of Role-Based Access Control (RBAC) is that users do not have discretionary access to enterprise objects. Instead, access permissions are administratively associated with roles, and users are administratively made members of appropriate roles. This idea greatly simplifies the management of authorization while providing an opportunity for great flexibility in specifying and enforcing enterprise- specific protection policies. It reduces the cost of administering access control policies as well as making the process less error-prone.
Figure 2.5 User-to-Role , Role-to-Operation mapping.
The relationship between user, role and operation is a many-to-many relationship. For example, a single user can be assigned a set of roles and a single role can have a set of user members. A role can perform a set of operations. And an operation can be performed by several roles.
The process of defining roles should be based on a thorough analysis of how an organization operates. Users can be made members of roles as determined by their responsibilities and qualifications and can be easily reassigned from one role to another without modifying the underlying access structure when the job assignment is changed. The operations that a user is permitted to perform are based on the user’s role. Roles can be granted new operations as new applications and actions are incorporated and operations can be revoked from roles as needed without updating the privilege for every user on an individual basis. This simplifies the administration and management of privileges.
2.5.3 Role Hierarchy
The capability for one role to inherit another role is a common feature of RBAC models. Roles can have overlapping responsibilities and privileges; that is, users belonging to different roles may need to perform common operations.
To make role definition and assignment even more convenient, roles may be organized hierarchically with one role implicitly including the operations, constraints, and objects that are associated with another role. In addition, role hierarchies also enhance the logical structuring of roles (e.g., if a hospital wishes to ensure that doctors can do all the things which nurses can do). In general, role hierarchies can be designed to reflect the responsibilities, authorities and competencies of groups within an organization.
2.5.4 Constrains
RBAC provides administrators the capability of imposing constrains on role design and user role assignment. There are two types of constraints: static separation of duties (ssd) and dynamic separation of duties (dsd) [BCF97, GB98].
A properly administered RBAC provides great flexibility and breadth of application which is achieved by statically and dynamically regulating users’ actions through the establishment and definition of roles, role hierarchies, relationships, and constraints.
CHAPTER 3
Security Services for Web-Based Workflow
In the chapter 2, we introduced some common security services and mechanisms. All those security services are needed for a Workflow Management System [WfMC98]. We explain why they are necessary for the workflow system in this chapter and we also discuss why we use Java for this project.
In most domains, it is critically important to limit access to data and tasks to authorized individuals. Before any subject (user/client) begins participating in a workflow they must be identified (who are they) and authenticated. Unique identification in a workflow system is based on the user's digital signatures, which use public/private keys. If anyone else is gets a user's private key, the system will be insecure. To minimize this risk, both physical and logical barriers should be set up to make stealing the private key difficult. Physical barriers include putting the private key on removable media (e.g., a floppy disk, CD or smart card). The user may then take the private key with them or lock it in a secure place. Since these may be stolen, it may also be important to have logical barriers (e.g., combinations of passwords, identifying information (name, SSN, birthday), fingerprints, and/or retinal scans).
Only authorized users should be allowed to execute given tasks or access given data objects. Access control must be effective in the sense that no unauthorized users should be granted access, while at the same time, no authorized user should be denied access.
In certain application areas (e.g., healthcare), security should not get in the way in a critical situation. In case of an emergency, certain authenticated users may temporarily assume greater privileges or a higher role. This is referred to a Break-Glass Procedure. Such unusual events should be recorded and the workflow administrator should be immediately informed. In addition, maximal auditing/tracking should be done until this user logs off from the higher role.
RBAC is used to determine what role(s) a subject (user/client) may perform. The role then determines what tasks a user may execute. Having established the identity of the user, we need to ensure that the user can only perform the roles he is entitled to. A workflow designer defines the roles for a particular workflow application then assigns one or more roles to each task in the workflow. A workflow administrator assigns users to specific roles using simple forms provided by the workflow repository, allowing convenient granting or revoking of roles.
At design time, a task is assigned a role expression (e.g. a set of roles). This approach is convenient in two distinct ways: (a) All users are not known at design time so it is infeasible to authorize users at this time. (b) A role groups together a collection of privileges (e.g., which tasks can be executed) so rather than assigning each user a long tedious list of privileges (ACL), they are simply assigned one or more roles. Therefore, RBAC provides an excellent foundation for security and for many organizations may suffice.
3.3 Data Confidentiality Service
For most network-based information systems, it is important that messages not be stolen because messages are likely to contain confidential information (e.g., medical patient records). To effectively guarantee this, sufficiently strong encryption should be used, so that no one will be able to decipher data flowing over the Net, except intended recipients. Symmetric key encryption algorithms are used to encrypt data since they are faster than public key algorithms. But symmetric key algorithms require complex key exchange. So the public key algorithms are used to send the symmetric key over the Net
Even if stolen messages are useless because they are encrypted, a malicious user may still cause problems. If s/he intercepts a message that is just a byte stream, modifies it and then sends it along, the message will no longer be valid. To ensure the message was not tampered with, a message authentication code (MAC) is calculated by applying a hash function to the message to form a digest. This digest is sent along with message (e.g., in a digital signature). Upon receipt of the message, the message is assumed to have been tampered-with, if the same hash function applied to the received message disagrees with the digest.
In a workflow setting, it is important to monitor all accesses. If user gains access illegally or a user makes a significant mistake, administrators must be able to quickly find out what has been done and by whom. Through sufficiently effective and reliable authentication and tracking, it should be possible to undeniably establish the identity of the individual responsible for executing a given task. The system must keep track of who executed each task and when it was executed. In general, WfMSs provide auditing, tracking and monitoring capabilities for purposes of evaluating the efficiency and effectiveness of elements within a workflow (e.g., automated tasks, workflow participants (end-users) as well as the overall workflow design itself). Of course, this information is also useful for security as well. If a security or privacy violation is suspected, utilities available to workflow administrators should facilitate such investigations.
3.6 Web-Based Application Security and Java
The Internet makes distributed processing possible. This new architecture divides web-based applications into components, each of which may exist and execute on different processors and in different locations. For a long time, Common Gateway Interface (CGI) scripts have been used to access to server side computing from HTML file pages downloaded to the client side. But this results in the server doing some jobs for the client in additional to his own. Java solves this easily by moving the load to the client side using applets. Java is an object-oriented language. It is architecture neutral, portable, robust, multithreaded and secure. Java, an execution platform born of the Net, has made distributed computing a practical reality while simplifying computing and empowering users.
As distributed components move among machines, the opportunity for breaches of security increases dramatically. For example, viruses can invade and destroy information on a user’s disk, unauthorized managers can steal credit card numbers when you buy things on line, confidential business files can be copied, etc.
Java offers a variety of ways to inspect, review, and restrict the execution of applications. It differs greatly from traditional approaches. For the traditional approaches, most operating systems permit applications broad access to system resources. It is the user's responsibility to ensure that resources are protected (e.g., permissions are set correctly). It is also the user's responsibility to verify a program's veracity before executing it (e.g., performing a virus scan). This approach has two obvious drawbacks: it relies on the user to perform the verification, and it relies on the accuracy of the verification software itself [Pfl97]. Also, the downloaded binary code is in the native computing mode of the local host. It is not as easy to inspect, review, and restrict as is an interpreted language like Java. Moreover, once executing, the host system can exercise only limited control on binary modules. This can lead to serious security breaches. But Java provides a powerful and highly flexible security features that make it suitable for the Internet and distributed computing systems. Security measures are an integral part of Java’s design. It includes two aspects:
Java language itself is designed to be type-safe. Unlike C/C++ it doesn’t support pointer arithmetic. So it eliminates the possibility of overwriting memory and corrupting data. Java language features such as automatic memory management, garbage collection, and range checking on strings and arrays are designed to help the programmer to write safe code.
3.6.1 Java Security Model
The Java virtual machine operates on a stream of bytecode as an interpreter. This means that it processes bytecode while the program is running and converts it to real machine code. Before the Java virtual machine can start this interpretation process, it has to do a number of things to set up the environment in which the program will run. This is the point at which the built-in security of Java is implemented. Java security model is shown in Figure 3.1.
Before a class loader may permit a given applet to execute, the bytecode verifier must verify applet's code. In fact, the verifier assumes that all code is meant to crash or penetrate the system’s security measures. The bytecode verifier traverses the bytecode, constructs the type state information, and verifies the types of the parameters to all the bytecode instructions [Pfl97]. The verifier ensures that the applets code which may not have been generated by a Java compiler play by the rules. Once the verifier is done, a number of important properties are known [Oak98]:
The bytecode verifier acts as a sort of gatekeeper: it ensures that code passed to the Java interpreter is in a fit state to be executed and can run without fear of breaking the Java interpreter.
Figure 3.1 Java Security Model
Class loaders separate the classes they load. They create and enforce a namespace hierarchy. Therefore, they can be used to ensure that an untrusted applet cannot interfere with the running of other programs.
All Java code, regardless of whether it is local or remote, can be subject to a security policy [GMP97]. When code is loaded, it is assigned "permissions" based on the security policy currently in effect. The security policy defines the set of permissions available for code from various signers or locations and can be configured by a user or a system administrator. Each permission specifies a permitted access to a particular resource, such as read and write access to a specified file or directory or connect access to a given host and port.
The runtime system organizes code into individual domains, each of which encloses a set of classes whose instances are granted the same set of permissions. The Java environment maintains a mapping from classes and instances to their protection domain and then to their permissions. The Security Manager checks sensitive accesses to crucial system resources:
Before any method that is part of the basic Java libraries is executed, it must consult the Security Manager.
3.6.2 Java Security APIs and Tools
The other part of Java security is the Java Security APIs. It provides a set of security tools and services.
The latest release of Java, JDK 1.2, contains a subset of cryptography functionality, including APIs for digital signatures, message digests and tools for keystore creation and management. It also provides services for algorithm parameter management, algorithm parameter generation, key factory and certificate factory. JDK 1.2 also enables a provider to supply a random-number generation (RNG) algorithm.
APIs for data encryption and decryption, key exchange and message authentication code (MAC) are released separately in a "Java Cryptography Extension" (JCE) package.
JDK1.2 introduces three new security related tools: keytool, jarsigner and policy tool.
The keytool is used to create key pairs, to import and display certificate chains, to export certificates, and to generate X.509 v1 self-signed certificates and certificate requests that can be sent to a certification authority.
The jarsigner tool is used for two purposes:
The jar archiving tool supports compression, but its most important capability from a security point of view is that it allows Java applets and their requisite components (.class files, images and sounds) to be downloaded to a client in a single HTTP transaction. This greatly improves the speed. Individual entries in a JAR file may be digitally signed by the applet author to authenticate their origin.
The jarsigner tool uses key and certificate information from a keystore to generate digital signatures for JAR files. A keystore is a database of private keys and their associated public key certificate.
Jarsigner uses an entity’s private key to generate a signature. A successful JAR file verification occurs if the signature(s) are valid, and none of the files that were in the JAR file when the signatures were generated have been changed since then.
The policy tool creates and modifies the policy configuration files that define your installation’s security policy.
3.6.3 Signed Applet
All Java users are taking security risks, because of the way Java works. Most Java code is automatically downloaded across the Internet and runs on your local machine, so the Java security model restricts what applets can do. Applet typically run under the scrutiny of a security manager. Each such applet is not allowed to access resources unless it is explicitly granted permission to do so by the security policy in effect.
Applets are not allowed to do the following [Oak98]:
These strictly enforced restrictions on untrusted Java code certainly help in gaining overall system security. However, they may also overly limit the power of applets. This is where signed applets come into the play. Those trusted applets in downloaded JAR files signed by a trusted entity are granted more permissions and may run with the same full rights as local applications.
To do this, a supplier bundles Java code (and any related files) into a JAR. The supplier then "signs" the applet using a digital signature and export the public key certificate corresponding to the private key used to sign the JAR file. The client needs to import the Certificate as a Trusted Certificate. He can verify the authenticity of the supplier by verifying the signature and set up a policy file to grant the required permission to the Java code. Detailed information about code signing can be found at appendix C.
CHAPTER 4
A Security Architecture for METEOR WfMSs and Its Implementation
In this chapter, we discuss how the above security mechanisms and solutions can be effectively combined and organized into an architecture for security in METOR WfMSs. In particular, the architecture requires message encryption, digital signatures and Role Based Access Control (RBAC).
This security system utilizes RBAC in providing access control services. Users (workflow participants) must login and select an appropriate role since proper authentication is the prerequisite of proper authorization. A Login Manager is in charge of the login procedure and the role selection procedure. It consults a Security Agent for user identification verification and a list of permitted roles associated with the user, if properly authenticated. The WorkList Manager launched by Login Manager is in charge of the associations of the role user currently plays and its permitted tasks and corresponding work items. It has to consult the Security Agent to see if the user is authorized to execute the tasks. The Scheduler for the task examines the user’s digital signature and/or role information to decide whether to permit the task to execute with the information provided by the Security Agent. Schedulers handle task authentication and data communication among different tasks. To prevent messages from being stolen or tampered with, communication between the system components is encrypted. The way in which these elements interact is shown in Figure 4.1, and discussed further in the subsections below. This is a fully distributed system, implemented using Java Remote Method Invocation (RMI). Hence, it provides scalability to the system. The Java Naming and Directory Interface (JNDI) is used to provide location-independent access to remote objects.
Figure 4.1 Security Architecture
4.2.1 Security Agent
In this subsection, we discuss the Security Agent and the security database. A relational database model is developed for the security database supporting RBAC. The Login Manager, Task Managers and Scheduler will consult the Security Agent in order to make security decisions. Only the Security Agent can access the security database. For performance reasons, multiple Security Agents may be utilized. However, in a network system, the up-to-data security information must be available to all managers. If we use multiple Security Agents, we must ensure the consistency of the security database. The security database needs to keep track of several types of entities that are richly connected in relationships. The entities are defined below and their attributes and relationships are shown in Figure 4.2.
Entities:
User = set of authorized workflow users/participants
Role domain = set of role domains
Role = set of roles played by users
Task = set of design-level tasks
The lower bound of role instance participated in the relationship collects is 1. It means the role domain name and role name together can be used to distinguish each role. Role hierarchy forms a directed acyclic graph (DAG) whose nodes correspond to roles in role domains. It is utilized in relationship subsume. The principle of mapping between roles and tasks is least privilege. According to role's job function, each role is assigned the minimum set of tasks this role can perform.
Figure 4.2 Security Database Design
A fundamental use of the security database is to determine whether a user may login under a role and execute a task. The Login Manager will ensure that the user has been authenticated and has been assigned the role. The task's Scheduler will ensure that the role is authorized to execute the task.
PublicKey pubKey = getPubKey( username );
Signature dsa=Signature.getInstance("SHA/DSA");
dsa.initVerify( pubKey );
dsa.update( message );
verifies = dsa.verify( userSignature );
// get all the roles this user’s current role contains
Vector roles = getRoles(userName, rootRoleName);
// get tasks for each role, then union
Enumeration rlEnum = roles.elements();
while ( rlEnum.hasMoreElements() ) {
roleName = (String)rlEnum.nextElement();
String qry = "Select * from RoleTask WHERE rolename = ‘" +
roleName +"’";
DBQuery dbq = new DBQuery( qry);
TaskList = dbq.getColumn("taskname");
union ( SumTaskList, TaskList);
}//while
Another responsibility of the Security Agent is key management. Without appropriate key management to generate, disseminate and destroy keys, security will become either unwieldy or ineffective. Each organization (or part of an organization) participating in workflows will need to disseminate keys, so ideally should also generate and destroy keys. The workflow administrator may use a utility provided by the Security Agent to produce unique key pairs for users. Some organizations may wish to get their keys from recognized Certificate Authorities (e.g., VeriSign) or from a trusted affiliated organization. Tools such as the Netscape Certificate Server allow organizations to conveniently generate keys. This piece of code below is used to generate key pairs. Private keys are store in a floppy disk while public keys are stored in security database.
KeyPairGenerator keyGen = KeyPairGenerator.getInstance("DSA");
keyGen.initialize(1024, new SecureRandom());
keypair = keyGen.generateKeyPair();
PersistentKeys.savePrivateKeyToFile( keypair.getPrivate(), Path );
PersistentKeys.savePublicKeyToDB( keypair.getPublic(), userName );
The user’s public key object is stored in the database. It has four member variables: p, q, g and y (p, q and g are algorithm parameters and y is the user's public key). We implement a persistent key class that can convert a public key object to a byte stream then convert the byte stream to a string which can be stored in the database. We use Java UCEncoding to convert a byte stream to string that only contains 64 characters:’0’-‘9’, ‘A’-‘Z’, ‘a’-‘z’, ‘(‘ and ‘)’. Then the string can be used as part of JDBC queries sent to a JDBC database without any trouble, since special characters may be restricted from the query language. UCEncoding use 3 bytes instead of 2 bytes to encode the message, so the length of message will increase.
public static String stringify( PublicKey publicKey ) {
try {
/* write the key object to a ByteArrayOutputStream object */
ByteArrayOutputStream bos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(bos);
oos.writeObject(publicKey);
oos.flush();
UCEncoder ucencoder = new UCEncoder();
return ucencoder.encodeBuffer(bos.toByteArray());
}
catch (Exception e) {
System.out.println(e);
return null;
}
}
Since the parameters of the public key object are the same for all the users, in the future, we should only store user’s public key y, which is much smaller than the public key object into the database. When the user’s public key (object) is needed, we should restore it using parameters and user’s public key y. Thus we can save a lot of space.
4.2.2 Login Manager
To participate in a workflow, a user carries out the following procedure. From a Web browser, the user enters the URL for the Login Manager. It is important that the Login Manager be authenticated using its own digital signature. This can be done by Signed applet. We also need to grant read and network permission to the Login Manager. Currently, the login script displays three buttons: Login, Logout and Quit.
A user types in his/her user name and role domain name, role name s/he is trying to perform from login script (role domain name and role name are optional since the user can browse all the roles s/he can perform and chose one). The Login Manager will generate a digital signature from the user’s private key loaded from his/her smartcard. The message will be encrypted by Security Agent’s public key and sent to Security Agent. The Security Agent decrypts the message and loads user’s public key form security database then verifies the signature. Once the user has been identified, the Login Manager will display a list of roles the user is authorized to perform. The user can choose a role that has been assigned or the roles he can perform from the role hierarchies. The login procedure is shown in Figure 4.3.
The user may logout from workflow procedure s/he is working on by clicking the Logout button. But the applet itself is still there, so the user may login again when s/he wants to play another role.
When Quit button is clicked, the memory image of the applet is cleared before exiting. The applet itself does not store anything persistently in files, databases, etc.
Figure 4.3 Authentication Procedure
4.2.3 WorkList Manager
Figure 4.4 Handle work items
Once a user has selected a role, Login Manager will launch WorkList Manager to display the list of user tasks this role is authorized to perform by consulting Security Agent shown in Figure 4.3. In Figure 4.4, T1 T2 and T3 are the tasks the user can execute shown in a browser. The user wants to execute T1 by clicking the button T1. The WorkList manager will display a list of work items the user can work on if the user is authorized, otherwise, a warning message will appear.
if ( authorized () ) {
buildMainForm ();
} else {
buildSecurityForm ();
};
4.2.4 Task Scheduler
After the work items displayed on the screen, the user can begin to work. The Task Scheduler is invoked when the user clicks the work item s/he wants to work on
When invoking a Task Scheduler, some security control information is sent along with the application data both encoded as name-value pairs.
Task_ID=<instance-id> & Task_Name=<task-name> &...<data>
User_Name=<user-name> & Digital_Signature=<user-signature> & Role_Name=<role>
This allows the Scheduler to uniquely identify the sender and make sure s/he is authorized to execute the task.
Figure 4.5 Task Scheduler
In Figure 4.5, we illustrate a Scheduler for human-computer task. The user wants to work on the item1. The Scheduler for the task T1 is invoked and some security control information is sent to him.
Upon receiving a message, the Scheduler must make sure that message was not forged or tampered with. This is accomplished using the message authentication code (digital signature, etc.) in the message.
The Scheduler must now consult the Security Agent to see if the requesting user has authorization by checking the user’s digital signature. Since the Scheduler and Security Agent may not be on a same host and Scheduler is not allowed to query the database, all the communication are done by remote method invocations. In order to improve the performance, the Scheduler maintains a cache of user information (including user name, user public key, user roles and tasks associated with those roles). Cached user information does not need network communication but does require that the cache be kept consistent with the up-to-date user information in the security database. The Scheduler will look up his cache first. If the Scheduler could not verify the user using information in the cache, it will consult the Security Agent. The Security Agent will do authentication and authorization and also return user information, so the Scheduler may cache the information for later use. If the user is authorized, the form and data for this item will be displayed, otherwise a warning message will be displayed. The checking consists of three steps:
The form for human-computer task displayed can come from two sources either an html file or hardcode in workflow application program, which is generated from code generator. If we use html file as a source, we have to plug this piece of code in.
HTMLDocument doc = (HTMLDocument)html.getDocument();
Element htmlElem = doc.getDefaultRootElement();
ElementIterator it = new ElementIterator(htmlElem);
Element next;
while ( (next = it.next()) != null )
{
AttributeSet attrs = next.getAttributes();
String name = (String)attrs.getAttribute(HTML.Attribute.NAME);
if( name == null ) continue;
HTML.Tag tag = (HTML.Tag) attrs.getAttribute
(StyleConstants.NameAttribute);
if( tag != HTML.Tag.INPUT ) continue;
String type = (String)attrs.getAttribute(HTML.Attribute.TYPE);
if( type.equals("text") )
{
Object model = attrs.getAttribute
(StyleConstants.ModelAttribute);
Document docValue = (Document)model;
String value = null;
try
{
value = docValue.getText( 0, docValue.getLength() );
}
catch( BadLocationException be )
{
//System.out.println("bad location: " + be);
value = null;
}
}
}
Regarding to non-repudiation, we must know which nurse administered the medications, not just that a nurse administered them. From the user’s digital signature, we know who executed this task and we also know what role the user was playing when he executed this task. This information should store in security database or workflow repository system for later use.
4.2.5 Secured Communication Channel
All the component of this system can be fully distributed. Remote method invocation is used for communication between different components. All the communication is encrypted. We were trying to use third party’s SSL implementation, but RSA public key algorithm is not free, so we implement a simplified SSL using the ELGamal algorithm to demonstrate how the secure communication channels work.
The ELGamal system [ELG85] is a public-key cryptosystem based on the discrete logarithm problem. Detailed information about ELGamal algorithm can be found in appendix A. Analysis based on the best available algorithms for both factoring and discrete logarithm shows that RSA and ELGamal have similar security for equivalent key lengths. The main disadvantage of ELGamal is the need for randomness, and its slower speed (especially for signing). Another potential disadvantage of the ELGamal system is that message expansion by a factor of two takes place during encryption. However, disadvantages are negligible if the cryptosystem is used only for exchange of secret keys such as in SSL. We discuss this in the next section.
4.2.5.1 Encryption of Communication
In this section, the implementation of our simplified SSL is introduced.
Figure 4.6 Simplified SSL
In Figure 4.6 (E stands for encryption algorithm and D stands for decryption algorithm), the client generates a symmetric key first, then encrypts it with server's ELGamal public key and sents it to the server. Only intended server can decrypt message since nobody else has the corresponding ELGamal private key. The server recovers the symmetric key and using it to encrypt data required by the client. In this way, the application data is secured. Since only the designated server can recover the symmetric key using his private key, the server is authenticated itself to the client.
4.2.4.2 Authentication between Different Components
The authentication of different components is done by SSL protocol. As discussed in last section, the server can authenticate himself to the client since nobody else has the private key corresponding to the public key used for encryption. In this section, we discuss client authentication, such as authentication between Login Manager and Security Agent, authentication between WorkList manager and Security Agent. In these cases, the Security Agent acts as SSL servers, while Login Managers and WorkList manager act as SSL clients.
As mentioned before, one of the Security Agent's duties is key management. Similar to generating key pairs for a user, it can also generate key pairs and certificate for Task Managers.
When a Worklist Manager communicates with a Scheduler, it sends its certificate and digital signature to the Scheduler. Upon receiving the message, the Scheduler extracts the WorkList manager's public key from his certificate and verifies the signature. Through this procedure, the Security Agent (sever) can authenticate the WorkList manager (client).
Based on the functionality this security system is to provide and the discussions presented in the previous chapter, Java and its technologies seem to be the right choice for implementation of such a security system.
All together, nine Java packages were written. They are illustrated in the Figure 4.7.
The Auth package provides the functionality of key generation, digital signatures, and symmetric key encryption. The ELGamal public key algorithm is put in a separate package. The Security Agent is in the package SecAgt. The Security Agent will consult the security database, do authentication and authorization. The database query APIs are in the myJDBC package. The classes for Login Manager are in LoginMgr package. All other classes related to the workflow, such as Task Manager and Schedule are put in SecFlow package. When using Java remote method invocation, RMI clients have to specify the registry’s host name or port number. In order to have location-independent access to remote objects, we developed package myJNDI, which implements a persistent flat namespace based on the Java naming and directory interface. The CodeGen package contains a code generator, which will generate application code from a WIL file. The application code generated form code generator is stored in the Apps package.
Figure 4.7 Package View
CHAPTER 5
Example: A "Secured" Web-Based Workflow
This chapter contains a fully illustrated example of a METEOR based workflow that has been implemented under the security architecture specified in the last chapter.
Figure 5.1 Workflow Design
We design a simple workflow using the METEOR workflow designer. This workflow has three human-computer tasks: EnterData, SignData and EndData, and one
automatic task, AutoTask. After the EnterData task is done, it will go to the next task SignData. According to the condition (the customer is female or male), the next task will be EndData or AutoTask.
Figure 5.2 Role Design
From role designer, we can see the role ProMgr subsume the privilege of role SrvRep in domain bell. Bell_SrvRep is authorized to execute EnterData Task and EndData Task. Bell_ProMgr is authorized to execute SignData task, and of course, the AutoTask. Because of there exists the role hierarchy, bell_ProMgr can execute EnterData and EndData also.
In order to start working with the workflow system, a user must first login through the Login Manager in the dialog box shown below.
Figure 5.3 Main Login Frame
After the user clicks on the login button, a new window pops up and lets user input the user’s name.
Figure 5.4 Login Frame
The other two fields, role domain name and role name, are optional at this point, because the Login Manager will consult the Security Agent and get all the roles this user can perform. So the user can pick up one as shown at figure 5.5.
Figure 5.5 Roles
Figure 5.6 Tasks
After the user picks up the role s/he is going to play at this time, the Login Manager will launch the WorkList manager, which will consult the Security Agent and display all the tasks this role can execute as shown in Figure 5.6.
In this case, the bell_SrvRep role can execute the task EnterData and EndData tasks. The number shown below each task button is the number of work-items for that task. They can be refreshed using the command from the pull-down menu.
EnterData is a start task and we can assume it is triggered by a customer phone call (so, the number of work items will always be zero). This service representative receives a phone call from customer John Smith so he clicks the EnterData button to execute EnterData task. The WorkList Manager will check if this user is allowed to perform this task by consult Security Agent. If the user is authorized, the form will be shown in Figure 5.7 and he can fill in the custom information, otherwise, a warning message is displayed in Figure 5.8.
Figure 5.7 Task: EnterData
Figure 5.8 Warning Message
After user fills out the information and submits this form, s/he can reset the form and working on the next customer.
As mentioned before, the data was encrypted and send to the Task Scheduler. According to some predefined condition, the Task Scheduler will locate the next task.
In Figure 5.9, we show a screen shot of the next task which is SignData. This task can be performed by ProMgr role at different locations on different machines. The information about this customer filled by the SrvRep role is clearly shown here, ProMgr role can fill out the other information. At the left side of screen, there is a list of work items waiting to be done.
After performing the user’s task, s/he can sign off the workflow system by pushing the Logout button or Quit button on the Login Manager dialog box.
The Logout button does not clear the memory, user can login again later when he wants to play another role. While the Quit button will logout the memory image of the applet. So after the user leave, no body can get any information out of this.
Figure 5.9 Task: SignData
CHAPTER 6
We have designed a security system for web-based workflow, which provides the following capabilities:
However, there is always room for improvements. Some of these are discussed below.
The responsibilities of a WorkList manager is to assign user a list of work items based on a specific assignment policy [Pro99]. For example, a user is assigned a work-item according his qualifications, availability, current workload and other business rules. How to provide this functionality at rune time is still an issue.
A workflow administrator needs to monitor and keep track of all accesses. He may want to know who executed a given task instead of which role executed the task (which nurse administered the medications, not just that a nurse administered them. From the user’s digital signature, we know who did this task and we also know what role the
user is playing when he executes this task. This information should be stored in workflow security database for later use or it can be stored into workflow repository system.
[BCF97] J. Barkley, A. Cincotta, D. Ferraiolo, S. Gavrilla, D.R. Kuhn. A Role Based Access Control Model and Reference Implementation within a Corporate Intranet. Technical report, NIST, 1997, URL: http://hissa.ncsl.nist.gov/rbac.
[Bark97] J. Barkley. Comparing Simple Role Based Access Control Models and Access control Lists. Technical report, NIST, 1997, URL: http://hissa.ncsl.nist.gov/rbac.
[CGC95] Cooper, F. J. Goggans, C. Halvey, J. Hughes, L. Morgan, L. Siyan, K. Stallings, W. Stephenson, P. Implementing Internet Security. New Riders Publishing, Indianapolis, IN, 1995
[ELG85] ELGamal, T. A public key cryptosystem and a signature scheme based on discrete logarithms. IEEE.
[Fis95] L. Fischer. The Workflow Paradigm - The Impact of Information Technology on Business Process Reengineering. Future Strategies, Inc., Alameda, CA, 2nd. edition, 1995.
[FKK96] A.O. Freier, P. Karlton, P.C. Kocher. SSL 3.0 Specification. Technical report, Netscape Communications Corporation, November 1996, URL: http://home.netscape.com/eng/ssl3/index.html.
[GB98] S. Gavrila, J. Barkley. Formal Specification for Role Based Access Control User/Role and Role/Role Relationship Management. Technical report, NIST, 1998.
[GHS95] Georgakopoulos, D. Hornick, M. Sheth, A. An Overview of Workflow Management: From Process Modeling to Workflow Automation Infrastructure. Distributed and Parallel Databases, 3(2):119--154, April 1995.
[GMP97] Gong, L. Mueller, M. Prafullchandra, H. Schemers, R. Going Beyond the Sandbox: An Overview of the New Security Architecture in the JavaTM Development Kit 1.2. USENIX Symposium on Internet Technologies and Systems, Monterey, California, 1997.
[GS97] Garfinkel, S. Spafford, G. Web Security & Commerce. O’Reilly & Associates, Cambridge, MA, 1997.
[Hol94] D. Hollingsworth. The Workflow Reference Model. Technical report, TC00-1003, Issue 1.1, The Workflow Management Coalition, Brussels, Belgium, 1994.
[JAD94] S. Joosten, G. Aussems, M. Duitshof, R. Huffmeijer, E. Mulder. WA-12: An Empirical Study about the Practice of Workflow Management. University of Twente, Enschede, The Netherlands, July 1994. Research Monograph.
[Jiang98] Jiang, Y. The Repository System of METEOR Workflow Management System. Masters thesis, Department of computer science, University of Georgia, 1998.
[Knu98] J. Knudsen. Java Cryptography. O’Reilly & Associates, Cambridge, MA, 1998.
[Kochut99] Kochut, K. J. Sheth, A. P. Miller, J. A. Optimizing Workflow. Component Strategies, Vol. 1, No. 9, 1999.
[KS95] N. Krishnakumar, A. Sheth. Managing Heterogeneous Multi-system Tasks to Support Enterprise-Wide Operations. Distributed and Parallel Databases, 3(2):155-186, 1995.
[Miller98] Miller, J. A. Palaniswami, D. Sheth, A. P. Kochut, K. J. Singh H. WebWork: METEOR2's Web-Based Workflow Management System. Journal of Intelligent Information Systems, 10, 185-215, 1997.
[NIS94] NIST. Digital Signature Standard. Technical report, NIST, May 1994. URL: http://www.itl.nist.gov/div897/pubs/fip186.htm.
[Oak98] S. Oaks. Java Security. O’Reilly & Associates, Cambridge, MA, 1998.
[Opp98] Rolf Oppliger. Internet & Intranet Security. Artech House, 1998.
[Opp96] Rolf Oppliger. Authentication Systems for Secure Networks. Artech House, 1996.
[Pfl97] C.P. Pfleeger. Security in Computing. Second Edition. Prentice Hall, Upper Saddle River, NJ, 1997.
[Pro99] Arpinar, I. B. A Proposal for Role Domain Design and Specification of Work-Item Assignment Strategies in METEOR. Technical report, Department of computer science, University of Georgia, 1999.
[SGJ96] A. Sheth, D. Georgakopoulos, S. Joosten, M. Rusinkiewicz, W. Scacchi, J. Wileden, A. Wolf. Report from the NSF Workshop on Workflow and Process Automation in Information Systems. Technical report, University of Georgia, UGA-CS-TR-96-003, July 1996. URL: http:// LSDIS.cs.uga.edu/activities/NSF-workflow.
[SKM96] A. Sheth, K. J. Kochut, J. Miller, D. Worah, S. Das, C. Lin, D. Palaniswami, J. Lynch, I. Shevchenko. Supporting State-Wide Immunization Tracking using Multi-Paradigm Workflow Technology. In Proc. of the 22nd. Intnl. Conference on Very Large Data Bases, Bombay, India, September 1996.
[Sta98] Stallings, W. Cryptography and Network Security: Principles and Practice. Prentice Hall Upper Saddle River, New Jersey, 1998.
[RGR97] Rubin, A. D. Geer, D. Ranum, M. J. Web Security Sourcebook. John Wiley & sons, New York, 1997
[WfMc98] Workflow Management Coalition Workflow Security Considerations WFMC-TC-1019, 1998.
Appendix A
1 Symmetric Key Algorithms
Typical symmetric key algorithms are DES, 3-DES, IDES, Blowfish, RC2, RC4, and RC5. We are using DES in the project that is provided in Java APIs.
Data Encryption Standard (DES) [NIST46] is a widely used method of data encryption, which was judged so difficult to break by the U.S. government that it was restricted for exportation to other countries. There are 72,000,000,000,000,000 (72 quadrillion) or more possible encryption keys that can be used.
A 64-bit key is used of which 56 bits are randomly generated and the other 8 bits is used for error detection. The decryption process is the reverse of the encryption process. A 64 bits data block to be enciphered is subjected to an initial permutation IP, then to a complex key-dependent computation and finally to a permutation which is the inverse of the initial permutation IP-1. The key-dependent computation can be simply defined in terms of a function f, called the cipher function, and a function KS, called the key schedule.
Let the permuted input data block be LR (32 bits respectably), calculate following equations:
Ln = Rn-1
Rn = Ln-1 + f ( Rn-1, Kn );
Kn = KS ( n, Key ) Where n = 1,2…16
The output of this computation is R16L16, which is then subjected to a permutation, which is the inverse of the initial permutation.
Upon receiving the data, the IP-1 permutation is applied to it. Then compute the following equations.
Rn-1 = Ln
Ln-1 = Rn + f ( Ln, Kn)
Kn = KS ( n, Key ) Where n = 16,15…1
And the result L0R0 is then subjected to the permutation IP and the original data is recovered.
Typical public key algorithms are Diffie-Hellman, RSA, ELGamal, and DSS. We implement ELGamal algorithm in the project. The DSS is discussed in the next appendix.
The ELGamal system [ELG85] is a public-key cryptosystem based on the discrete logarithm problem. The system parameters consist of a prime number p and an integer g, whose powers modulo p generate a large number of elements, as in Diffie-Hellman.
For example, Alice has a private key a and a public key y, where y = ga (mod p). Suppose Bob wishes to send a message m to Alice. Bob first generates a random number k less than p. He then computes
y1 = gk (mod p)
y2 = m Å yk (mod p)
where Å denotes the bit-wise exclusive-or operation. Bob sends (y1 ,y2) to Alice. Upon receiving the ciphertext, Alice computes following equation to get the original message.
m = (y1a mod p) Å y2
Analysis based on the best available algorithms for both factoring and discrete logarithm shows that RSA and ELGamal have similar security for equivalent key lengths. The main disadvantage of ELGamal is the need for randomness, and its slower speed
(especially for signing). Another potential disadvantage of the ELGamal system is that message expansion by a factor of two takes place during encryption. However, disadvantages are negligible if the cryptosystem is used only for exchange of secret keys.
Encryption:
// get algorithm parameters
BigInteger p = pubkey.getP();
BigInteger g = pubkey.getG();
//generate a random BigInteger k, 0 < k < p
BigInteger k = new BigInteger(lp.lengthBits, new Random() );
while ( k.compareTo(BigInteger.ZERO) !=1 || k.compareTo(p) != -1 ) {
k = new BigInteger(lp.lengthBits, new Random() );
} //while
// calculate y1
y1 = g.modPow(k, p);
BigInteger toXorWith = (pubkey.getKey() ).modPow(k, p);
y2 = xor(message, toXorWith);
If the length of the message is larger than the length of toXorWith, the message have to be broken into pieces and the last piece may need padding. After doing xor one by one, the encrypted message fragments are combined together. Y1 and Y2 are put into the class txMgrPair and sent over the Net.
Decryption:
BigInteger toXorWith = y1.modPow
(privatekey.getKey(),privatekey.getP());
DecryptedMsg = xor(y2, toXorWith);
Similar to encryption, if the length of the cipher text is larger then toXorWith, it has to be broken into pieces too.
Encrypted message will be sent over the Net, so the object txMgrPair has to implement serializable interface by implementing the readObject and writeObject methods.
private void writeObject( ObjectOutputStream out)
throws IOException{
out.writeObject(y1);
out.writeObject(y2);
}
private void readObject( ObjectInputStream in)
throws IOException, ClassNotFoundException{
y1 = (BigInteger)in.readObject();
y2 = (BigInteger)in.readObject();
}
Appendix B
The digital signature standard (DSS), proposed by the National Institute of Standards and Technology, (NIST) refers to an optimized modification of the ELGamal cryptosystem [NIST94].
The digital signature algorithm makes use of following Parameters:
1. DSA parameters: p, q are prime numbers, and g is an integer
2. sender’s private key x is a random integer
3. sender’s public key y = gx mod p
4. a random integer k
The integer p, q, and g can be public. Parameters x and k are used for signature generation only, and must be kept secret.
To generate a digital signature, a digest is formed by applying a hash function SHA (Secure Hash algorithm, NIST, FIPS 180) to the original message
The output of this algorithm is a 160-bit digest. Then the sender uses his private key x to compute following values:
r = (gk mod p) mod q |r|=160 bit
s = (k-1(SHA(M) + xr)) mod q |s|=160 bit
The signature is the pair of integer r and s.
Figure A Digital Signature
Then sender sends signed message along with digital signature to the receiver. Both r and s are large integers (160 bits) and together form the digital signature (k is a random integer).
Let’s say M’, r’ and s’ are the received versions of M, r, and s, respectively. The receiver computes following functions:
w = s'-1 mod q
u1= ((SHA(M’)w) mod q
u2 = ((r’)w) mod q
v = ((gul * yu2) mod p) mod q.
If v = r’, then the signature is verified and the receiver is sure that the received message was sent by the party holding the private key x corresponding to y. If v does not equal r’, then the message is invalid.
The security of this algorithm relies on difficulty of computing discrete logarithm over finite fields. Attacks for recovering the sender’s private key x or for forging signatures without recovering x are impossible.
Appendix C
By signing applet and granting it permissions, an applet may run with the same full rights as local applications. We use Java security tools to accomplish this. The information in this appendix comes from Java tutorial: Signing Code and Granting It Permissions.
Steps for the applet signer Alice:
jar cvf Alice.jar Alice.class
keytool -genkey -alias signFiles -keypass kpi135 -keystore alicestore -storepass ab987c
The keytool command creates the keystore named alicestore and assigns it the password ab987c. The command generates a public/private key pair and a certificate for Alice. The certificate is associated with the private key in the keystore entry referred to by the alias signFiles. The private key is assigned the password kpi135.
jarsigner -keystore alicestore -signedjar sAlice.jar Alice.jar signFiles
Copy Alice's certificate from the keystore to a file named Alice.cer via the following then send it to Bob.
keytool -export -keystore alicestore -alias signFiles -file Alice.cer
Steps for the code receiver Bob:
keytool -import -alias Alice -file Alice.cer -keystore bobstore
To start Policy Tool, type the command: policytool
Figure A Policy Tool
Then Bob specifies where his policy file is and where is his keystore, then click add policy entry to add a new entry.
Leave the CodeBase text box blank, to grant all code signed by Alice the permission, no matter where it comes from. Type alice into Signedby text box. Then add permissions to the code signed by Alice by click Add Permission button.
Figure B Policy Entry
Select File Permission from Permission drop-down list, Specify the name of the files this permission is applied to, Specify read access by choosing the read option from the Actions drop-down list. Click the OK button and save the policy file.
Figure C Grant Permissions
Here is the sample policy file.
keystore "file:/home/grads/bob/bobstore";
grant signedBy "alice" {
permission java.io.FilePermission "<<ALL FILES>>", "read";
};