- Email: [email protected]
Authorization Models — PKI Versus the Real World
Information Security Technical Report, Vol 5, No. 4 (2000) 66-71
Authorization Models — PKI Versus the Real World Steve Matthews, Netlexis UK The widely marketed Public Key Infrastructure as a means of securing business by electronic means requires communication between individuals. Most business models communicate with groups and relate roles to individual actors. Can these models be resolved efficiently and securely? Are new mechanisms needed or can you re-work existing technologies?
Introduction The technology of the Public Key Infrastructure (PKI) has developed out of a feature of asymmetric cryptography: that one of a linked pair of cryptographic keys can be safely published without disclosing sufficient of the other key that it can be compromised. The pair of keys corresponds to an ‘electronic identity’ which may, under suitable circumstances, be associated with the identity of an individual. The nature of the mechanisms currently available to protect the key that is not published (the private key), and emerging legislation concerning the legality of linking an individual to an identity using a digital signature, are such that where an individual is linked to a private key, the individual must be able to have full control over the key. Ignoring security considerations for the moment, these operational requirements mean that individuals cannot make use of shared private keys because those keys cannot be bound readily to any individual. Taking security considerations into account, the likelihood of compromise increases where
66
more individuals have control over a private key. This ‘individualist’ nature of both the mechanisms and the legislation militate against the common business requirement to be able to share, between members of a ‘group’, information which is cryptographically protected. The use of role as a means of describing expected (or intended) behaviour is commonly used in many modelling methodologies and in an increasing number of standards. IS 14662, the Open-EDI Reference Model makes use of role as a means of characterizing behaviour of Open-EDI parties. Role is used in entity/state models, and is mentioned in draft regulation such as HIPAA (US medical information controls) as a means of labelling actual or claimed authority. Role has indeed proved valuable in determining two different aspects of information management. The first is defining the authority possessed by the identity having the ability to use the role and the second is identifying the types of information that are to be associated with an identity able to use the role. Role is not, however, formally defined. Everyone ‘knows’ what a role is supposed to mean, but there is very little agreement about the definition of a specific role. A dentist, for example, may have the qualification of medical doctor, and may perform that role, but should not be confused with the general practitioner, who is also a medical doctor.
0167-4048/00/$20.00 © 2000, Elsevier Science Ltd
Authorization Models – PKI Versus the Real World
Problems for Role Definition Role, although conceptually simple to state, appears more difficult to define in detail. If we take as an example the two classical roles in the simplest commercial transaction, buyer and seller, we can make the following observations: • Buyer — a role well defined in law, may require further dimensions such as; capacity to make a transaction, level of authority for a monetary sum, either per transaction or in aggregate, requirements for co-signing, ability to make commitment. • Seller — again well defined in law, but is there a capacity to perform the transaction, is there a liability on failure to perform the transaction, is there the authority to perform the transaction (selling of controlled substances or those requiring licenses). Further, the roles we have just considered are largely determined by assertion (the buyer and seller, in a simple transaction, may perform the other role just as readily). There are many instances where a role cannot be performed because a statutory authority, regulator or professional institute recognized by law does not recognize the individual (or the business entity) as having the role available. Typical examples include the roles of medical doctor, pharmacist, lawyer, accountant, independent financial adviser, bank, insurer, and so on. This is a preamble to noting that whilst some roles may be claimed as mere statements by the entities concerned, others require attestation from third parties.
Issues When Implementing Roles for Authority Therefore, the use of roles as a means of facilitating electronic interchange requires
Information Security Technical Report, Vol. 5, No. 4
either the use of multiple entities to provide the binding(s) needed to satisfy the use of a claimed role, or a mechanism of liability that allows other parties to the interchange to obtain redress where a claimed role proved false. Implementing roles using a mechanism such as PKI therefore sets a number of different requirements: • The role may be claimed as part of the identity (linked immediately to it as an integral part of the certificate issued by a specific certification authority (CA) where the CA accepts liability for publishing the statement. • The role may be claimed by linking the distinguished name (or some unique provable reference) to a distinguished name (or reference) in another CA which itself accepts liability for publishing the statement. • The role may be claimed where there is a link to a CA which has a statutory duty to provide such information which may be relied upon in law. The simplest of these is obviously the first, and it would be most convenient if it satisfied all cases. Unfortunately, if we take the simple case of buyer, whilst it may be elegant to say that the CA of the buyer can assert that the identity has the role of buyer with a number of capacities, the seller is going to place reliance upon other factors, including: • Has the claimed identity been granted that role by an undertaking between the organizations? • Has any part of that identity carried out a transaction previously, and with what results?
67
Authorization Models – PKI Versus the Real World
• What is the overall exposure to the organization represented by the distinguished name to the seller? • Is the role claimed appropriate to the nature of the interchange, and, if not, what additional role(s) would be required and are they claimed also? These issues arise because of an interaction outside the domain of an organization and will not impact where control of role definition and role allocation and liability for allocation of role to an identity all lie within the same span of control. Thus a healthcare management organization (or health trust) may allocate the roles of doctor, surgeon, nurse, pharmacist etc. within their own boundary, but those roles may not be capable of recognition outside that boundary. As a result, two healthcare bodies may have apparently identical roles (as seen from the outside) without them actually corresponding. From the PKI perspective, implementation of solely internal rules should not present significant problems. The definition of a role that is something internal can be done in a purely proprietary manner because there is no reason to consider external requirements. Even where there is limited external interaction, this could be catered for by the issuing of internal certification to the outsiders, or, if the capability is available, registering the outsider ’s credentials as internal ones for the purpose of creating the necessary links between certificate and role. As a separate point, there may be some difficulties if multiple certificates are to be imported, each performing a different function (identity, signing authority, confidentiality and so on). That could occur if there is no clear mechanism for recognizing
68
each function, or where the CA has a requirement to have knowledge of a private key that the external user may not wish to disclose. These situations may occur if there is a need to perform certain types of key recovery because of constraints in the implementation of the PKI. Where implementations require external interfaces, the issues are perhaps more problematic. Role information may have to contain quite a large amount of additional information for it to be useful. The full link to the external source of the role has to be made available. This would have to include the full distinguished name to be relied upon, the address of the CA publishing the certificate, the address of the revocation list of that CA and the revocation implementation, the public key of the CA and the address of the guaranteeing CA and its revocation list. In addition, roles referred to in this way would have to be registered by some means that ensured a common implementation of the processing of the authority of the role such that it was consistent at all times. This requirement would create some automatic limitations, in that roles defined by regulation could be easily specified and published by relevant national body authorities (perhaps the formal standards bodies of nation states would be safest). This would not address or solve the issue of discontinuity of roles between nation states (the remit of a notary will be very different in France as in the USA), however, it would serve to provide a point of interface. It may well be that the interchange of role controlled information may have to follow a very structured path, rather than the free access continually proposed by the Internet. That may not, indeed, prove a retrograde step. Perhaps information can be more readily transferred from a government department in
Information Security Technical Report, Vol. 5, No. 4
Authorization Models – PKI Versus the Real World
one state to its broad equivalent in another, leaving those playing subservient roles controlled by internal administration. The same may prove true for hospitals. There are emerging models for intra-governmental interchanges using methods such as the ‘bridge CA’ where a common high level role may be administratively possible, the rest of the legal control being the subject of international treaty, memorandum of understanding or protocol or some similar instrument. The adoption of a high level role for the purpose of external interchange could simplify a number of the issues that have been raised. What it does not solve is the ability of the public user to make an ‘informed decision’ upon the nature of the interchange taking place. Considerably more thought is required in order to provide the level of understanding needed over the use of role and the verification of claimed roles. In many cases there is a positive argument for limiting the exposure to the claim of a role to the extent of the liability that can be enforced. In this area, PKI may perform a useful capability by ensuring that there is a consistency between roles being asserted by CAs and the remedy available where the assertion is shown to be false. Work on certificate classification may be valuable in establishing this link, particularly in Europe where the concept of the ‘qualified certificate’ is being developed. These observations address the authority conveyed by role. We must not, however, ignore the question of information sharing using cryptographic controls.
Issues When Implementing Roles for Information Control Previously, information sharing has been facilitated by the use of access control mechanisms rather than by cryptography.
Information Security Technical Report, Vol. 5, No. 4
This has been possible because system protection and controls were based upon inaccessibility of information rather than facilitation. Web-based developments have created a new environment where information is gathered from individuals playing roles. Very often the information being gathered must be available to others that are able to use that role, but must be protected from any that do not have that role (including, especially systems and network administrators). Role has a potential use when related to information because it is able to specify one or more classes of users that may be entitled to some authority over the information. Examples of this form include where information has been collected that can only be made available to a medical doctor or a lawyer or a police officer. Role here connects the users with the nature of the information, and may be useful to demonstrate compliance with legislation such as the Data Protection Directive, or the Safe Harbors proposal or the HIPAA proposals. Unless there is a connection between role, authority and use then the ability to demonstrate compliance cannot be achieved. Compliance, in such cases, is demonstrated by the proof that only those that had available the role and the authority could have processed the information to the extent that was permitted. Such an approach is of use to a data controller. If that approach is not used the data controller has a problem demonstrating that they cannot have revealed information to those who did not have appropriate authority. Here, the definition of role is much simpler because it is an internally controlled definition. The controller is able to define roles (or labels) which are useful for internal administration without having to agree them with others.
69
Authorization Models – PKI Versus the Real World
It is important to consider in the implementation of such a scheme how cryptographic integrity may be maintained. Obviously each role holder must be in possession of, or be able to gain access to the public key of the role they are authorized for. This does not present a security weakness, in that the public key is published in any event. The role holder must have established adequate proof of identity consistent with the claim of the role. Information created by the role holder must be signed with their own private key but encrypted with the public key of the role. At the point of data storage it is possible to verify the authenticity of the information being stored and no further action is required. When a role holder requests information, again their authority can be verified. However, centrally, the private key related to the confidentiality of that role must be located so that the ‘session key’ used when storing the information can be re-encrypted under the individual’s public key. There is, therefore, a requirement to have a secure conversion server in order to protect the role-based private keys and access them to provide the conversions needed. Such a server would have to be able to recognize where multiple roles had authority over information and be able to select the private key corresponding to the role of the user that had originated the information regardless of the fact that it may not be the role for which the current user is authorized. This implies that role, used as a label, must be tagged onto the information such that it can be read by the server in clear text, but signed by the originator so that the role list cannot be altered. This last point presents the systems designer with a challenge if a new role has to be added to existing information, since the guarantor of authenticity is going to be a computerized process (or an administrator) and not the originator of the information. One approach to solving this problem might be to
70
have the originator sign the information and the system sign the role list. This would not remove the possibility of role compromise, but segregation of duties and separation of processing actions would act to reduce the potential for easy external compromise.
Issues When Implementing Groups Most of society is conveniently organized into groups. Grouping is, and will probably remain, a convenient administrative approach. The prevalence of tools that allow an administrator to ‘drag and drop’ complete definitions onto systems should indicate that this form of administration, even if not appropriate in all circumstances, is of considerable importance. Groups differ from roles in that there is an implicit assumption that information is to be shared within and among a group, whereas a role, on its own, may not be sufficient evidence of authority. PKI, in its current form, is constructed to manage one-to-one relationships but is less than ideal when presented with one-to-many or many-to-many relationships. One approach to the one-to-many, as considered in S/MIME, is to attach all the recipient keys to the information being interchanged. This creates a number of problems in implementation, including the need to be able to access all the keys of a group and the time and effort taken to perform all the cryptographic transformations. It is difficult to solve transformation problems when a ‘push’ model is used for interchange. This is because if information is moved directly to its recipient it must be in a form for that recipient to receive. It could be solved by distributing the private keys of the group to all users, as well as the public keys. This would be reasonable if it is possible to protect the
Information Security Technical Report, Vol. 5, No. 4
Authorization Models – PKI Versus the Real World
private group key to the same extent as the private key of the user. It is possible to do this, and to ensure secure key transmission by encrypting this private key under the public key of the recipient. The weakness in this approach is effective ceasing of the use of the group key once issued. If the group key is not the primary means of gaining access to the system, or ceasing the ‘master’ private key has the effect of denying access to the encrypted materials the approach may be valid. Designers considering such an approach will have to take account of the problems created by the mobile (or laptop) user who may not reauthenticate to a control system in order to access or interchange information. An alternative approach may be to make use of a forwarding mechanism to provide the key transformations which otherwise would have to take place with the sender. Such a forwarding mechanism would have to control the private group keys and be able to determine members of the group with reference to whatever is the distribution list for the interchange. In services such as E-mail this approach may be acceptable since commonly E-mail interchanges take place through a server mechanism. In other services it is more difficult to comment since the implementations may be more varied, although Web-based services would all pass through one or more servers prior to completion. Workflow systems would be able to use a server-based mechanism since they manage information flows.
Information Security Technical Report, Vol. 5, No. 4
By comparison, pull-based systems for group work will be able to use a server-based transformation system because they can implement an authorization check when a request for information is made. In these environments it is only necessary for group users to have access to the public group keys. This does not protect the system from nongroup members being able to proffer information encrypted for the group, however, the server mechanism will be able to detect these through the failure to match the signature to a member of the group and reject them at that stage.
Summary and Conclusions The PKI environment as currently implemented is not ideal for supporting the concepts of role and group in one-to-many and many-to-many situations. The mechanism restricting the use of a private key to a single entity is essential for satisfying emerging legal controls. However, it creates some practical difficulties where information must be available to wider groups and confidentiality has to be maintained through the overall process. This paper suggests a number of ways in which the current PKI environment could be enhanced in order to provide more commercial applications and commercial implementations.
71
Authorization Models — PKI Versus the Real World Steve Matthews, Netlexis UK The widely marketed Public Key Infrastructure as a means of securing business by electronic means requires communication between individuals. Most business models communicate with groups and relate roles to individual actors. Can these models be resolved efficiently and securely? Are new mechanisms needed or can you re-work existing technologies?
Introduction The technology of the Public Key Infrastructure (PKI) has developed out of a feature of asymmetric cryptography: that one of a linked pair of cryptographic keys can be safely published without disclosing sufficient of the other key that it can be compromised. The pair of keys corresponds to an ‘electronic identity’ which may, under suitable circumstances, be associated with the identity of an individual. The nature of the mechanisms currently available to protect the key that is not published (the private key), and emerging legislation concerning the legality of linking an individual to an identity using a digital signature, are such that where an individual is linked to a private key, the individual must be able to have full control over the key. Ignoring security considerations for the moment, these operational requirements mean that individuals cannot make use of shared private keys because those keys cannot be bound readily to any individual. Taking security considerations into account, the likelihood of compromise increases where
66
more individuals have control over a private key. This ‘individualist’ nature of both the mechanisms and the legislation militate against the common business requirement to be able to share, between members of a ‘group’, information which is cryptographically protected. The use of role as a means of describing expected (or intended) behaviour is commonly used in many modelling methodologies and in an increasing number of standards. IS 14662, the Open-EDI Reference Model makes use of role as a means of characterizing behaviour of Open-EDI parties. Role is used in entity/state models, and is mentioned in draft regulation such as HIPAA (US medical information controls) as a means of labelling actual or claimed authority. Role has indeed proved valuable in determining two different aspects of information management. The first is defining the authority possessed by the identity having the ability to use the role and the second is identifying the types of information that are to be associated with an identity able to use the role. Role is not, however, formally defined. Everyone ‘knows’ what a role is supposed to mean, but there is very little agreement about the definition of a specific role. A dentist, for example, may have the qualification of medical doctor, and may perform that role, but should not be confused with the general practitioner, who is also a medical doctor.
0167-4048/00/$20.00 © 2000, Elsevier Science Ltd
Authorization Models – PKI Versus the Real World
Problems for Role Definition Role, although conceptually simple to state, appears more difficult to define in detail. If we take as an example the two classical roles in the simplest commercial transaction, buyer and seller, we can make the following observations: • Buyer — a role well defined in law, may require further dimensions such as; capacity to make a transaction, level of authority for a monetary sum, either per transaction or in aggregate, requirements for co-signing, ability to make commitment. • Seller — again well defined in law, but is there a capacity to perform the transaction, is there a liability on failure to perform the transaction, is there the authority to perform the transaction (selling of controlled substances or those requiring licenses). Further, the roles we have just considered are largely determined by assertion (the buyer and seller, in a simple transaction, may perform the other role just as readily). There are many instances where a role cannot be performed because a statutory authority, regulator or professional institute recognized by law does not recognize the individual (or the business entity) as having the role available. Typical examples include the roles of medical doctor, pharmacist, lawyer, accountant, independent financial adviser, bank, insurer, and so on. This is a preamble to noting that whilst some roles may be claimed as mere statements by the entities concerned, others require attestation from third parties.
Issues When Implementing Roles for Authority Therefore, the use of roles as a means of facilitating electronic interchange requires
Information Security Technical Report, Vol. 5, No. 4
either the use of multiple entities to provide the binding(s) needed to satisfy the use of a claimed role, or a mechanism of liability that allows other parties to the interchange to obtain redress where a claimed role proved false. Implementing roles using a mechanism such as PKI therefore sets a number of different requirements: • The role may be claimed as part of the identity (linked immediately to it as an integral part of the certificate issued by a specific certification authority (CA) where the CA accepts liability for publishing the statement. • The role may be claimed by linking the distinguished name (or some unique provable reference) to a distinguished name (or reference) in another CA which itself accepts liability for publishing the statement. • The role may be claimed where there is a link to a CA which has a statutory duty to provide such information which may be relied upon in law. The simplest of these is obviously the first, and it would be most convenient if it satisfied all cases. Unfortunately, if we take the simple case of buyer, whilst it may be elegant to say that the CA of the buyer can assert that the identity has the role of buyer with a number of capacities, the seller is going to place reliance upon other factors, including: • Has the claimed identity been granted that role by an undertaking between the organizations? • Has any part of that identity carried out a transaction previously, and with what results?
67
Authorization Models – PKI Versus the Real World
• What is the overall exposure to the organization represented by the distinguished name to the seller? • Is the role claimed appropriate to the nature of the interchange, and, if not, what additional role(s) would be required and are they claimed also? These issues arise because of an interaction outside the domain of an organization and will not impact where control of role definition and role allocation and liability for allocation of role to an identity all lie within the same span of control. Thus a healthcare management organization (or health trust) may allocate the roles of doctor, surgeon, nurse, pharmacist etc. within their own boundary, but those roles may not be capable of recognition outside that boundary. As a result, two healthcare bodies may have apparently identical roles (as seen from the outside) without them actually corresponding. From the PKI perspective, implementation of solely internal rules should not present significant problems. The definition of a role that is something internal can be done in a purely proprietary manner because there is no reason to consider external requirements. Even where there is limited external interaction, this could be catered for by the issuing of internal certification to the outsiders, or, if the capability is available, registering the outsider ’s credentials as internal ones for the purpose of creating the necessary links between certificate and role. As a separate point, there may be some difficulties if multiple certificates are to be imported, each performing a different function (identity, signing authority, confidentiality and so on). That could occur if there is no clear mechanism for recognizing
68
each function, or where the CA has a requirement to have knowledge of a private key that the external user may not wish to disclose. These situations may occur if there is a need to perform certain types of key recovery because of constraints in the implementation of the PKI. Where implementations require external interfaces, the issues are perhaps more problematic. Role information may have to contain quite a large amount of additional information for it to be useful. The full link to the external source of the role has to be made available. This would have to include the full distinguished name to be relied upon, the address of the CA publishing the certificate, the address of the revocation list of that CA and the revocation implementation, the public key of the CA and the address of the guaranteeing CA and its revocation list. In addition, roles referred to in this way would have to be registered by some means that ensured a common implementation of the processing of the authority of the role such that it was consistent at all times. This requirement would create some automatic limitations, in that roles defined by regulation could be easily specified and published by relevant national body authorities (perhaps the formal standards bodies of nation states would be safest). This would not address or solve the issue of discontinuity of roles between nation states (the remit of a notary will be very different in France as in the USA), however, it would serve to provide a point of interface. It may well be that the interchange of role controlled information may have to follow a very structured path, rather than the free access continually proposed by the Internet. That may not, indeed, prove a retrograde step. Perhaps information can be more readily transferred from a government department in
Information Security Technical Report, Vol. 5, No. 4
Authorization Models – PKI Versus the Real World
one state to its broad equivalent in another, leaving those playing subservient roles controlled by internal administration. The same may prove true for hospitals. There are emerging models for intra-governmental interchanges using methods such as the ‘bridge CA’ where a common high level role may be administratively possible, the rest of the legal control being the subject of international treaty, memorandum of understanding or protocol or some similar instrument. The adoption of a high level role for the purpose of external interchange could simplify a number of the issues that have been raised. What it does not solve is the ability of the public user to make an ‘informed decision’ upon the nature of the interchange taking place. Considerably more thought is required in order to provide the level of understanding needed over the use of role and the verification of claimed roles. In many cases there is a positive argument for limiting the exposure to the claim of a role to the extent of the liability that can be enforced. In this area, PKI may perform a useful capability by ensuring that there is a consistency between roles being asserted by CAs and the remedy available where the assertion is shown to be false. Work on certificate classification may be valuable in establishing this link, particularly in Europe where the concept of the ‘qualified certificate’ is being developed. These observations address the authority conveyed by role. We must not, however, ignore the question of information sharing using cryptographic controls.
Issues When Implementing Roles for Information Control Previously, information sharing has been facilitated by the use of access control mechanisms rather than by cryptography.
Information Security Technical Report, Vol. 5, No. 4
This has been possible because system protection and controls were based upon inaccessibility of information rather than facilitation. Web-based developments have created a new environment where information is gathered from individuals playing roles. Very often the information being gathered must be available to others that are able to use that role, but must be protected from any that do not have that role (including, especially systems and network administrators). Role has a potential use when related to information because it is able to specify one or more classes of users that may be entitled to some authority over the information. Examples of this form include where information has been collected that can only be made available to a medical doctor or a lawyer or a police officer. Role here connects the users with the nature of the information, and may be useful to demonstrate compliance with legislation such as the Data Protection Directive, or the Safe Harbors proposal or the HIPAA proposals. Unless there is a connection between role, authority and use then the ability to demonstrate compliance cannot be achieved. Compliance, in such cases, is demonstrated by the proof that only those that had available the role and the authority could have processed the information to the extent that was permitted. Such an approach is of use to a data controller. If that approach is not used the data controller has a problem demonstrating that they cannot have revealed information to those who did not have appropriate authority. Here, the definition of role is much simpler because it is an internally controlled definition. The controller is able to define roles (or labels) which are useful for internal administration without having to agree them with others.
69
Authorization Models – PKI Versus the Real World
It is important to consider in the implementation of such a scheme how cryptographic integrity may be maintained. Obviously each role holder must be in possession of, or be able to gain access to the public key of the role they are authorized for. This does not present a security weakness, in that the public key is published in any event. The role holder must have established adequate proof of identity consistent with the claim of the role. Information created by the role holder must be signed with their own private key but encrypted with the public key of the role. At the point of data storage it is possible to verify the authenticity of the information being stored and no further action is required. When a role holder requests information, again their authority can be verified. However, centrally, the private key related to the confidentiality of that role must be located so that the ‘session key’ used when storing the information can be re-encrypted under the individual’s public key. There is, therefore, a requirement to have a secure conversion server in order to protect the role-based private keys and access them to provide the conversions needed. Such a server would have to be able to recognize where multiple roles had authority over information and be able to select the private key corresponding to the role of the user that had originated the information regardless of the fact that it may not be the role for which the current user is authorized. This implies that role, used as a label, must be tagged onto the information such that it can be read by the server in clear text, but signed by the originator so that the role list cannot be altered. This last point presents the systems designer with a challenge if a new role has to be added to existing information, since the guarantor of authenticity is going to be a computerized process (or an administrator) and not the originator of the information. One approach to solving this problem might be to
70
have the originator sign the information and the system sign the role list. This would not remove the possibility of role compromise, but segregation of duties and separation of processing actions would act to reduce the potential for easy external compromise.
Issues When Implementing Groups Most of society is conveniently organized into groups. Grouping is, and will probably remain, a convenient administrative approach. The prevalence of tools that allow an administrator to ‘drag and drop’ complete definitions onto systems should indicate that this form of administration, even if not appropriate in all circumstances, is of considerable importance. Groups differ from roles in that there is an implicit assumption that information is to be shared within and among a group, whereas a role, on its own, may not be sufficient evidence of authority. PKI, in its current form, is constructed to manage one-to-one relationships but is less than ideal when presented with one-to-many or many-to-many relationships. One approach to the one-to-many, as considered in S/MIME, is to attach all the recipient keys to the information being interchanged. This creates a number of problems in implementation, including the need to be able to access all the keys of a group and the time and effort taken to perform all the cryptographic transformations. It is difficult to solve transformation problems when a ‘push’ model is used for interchange. This is because if information is moved directly to its recipient it must be in a form for that recipient to receive. It could be solved by distributing the private keys of the group to all users, as well as the public keys. This would be reasonable if it is possible to protect the
Information Security Technical Report, Vol. 5, No. 4
Authorization Models – PKI Versus the Real World
private group key to the same extent as the private key of the user. It is possible to do this, and to ensure secure key transmission by encrypting this private key under the public key of the recipient. The weakness in this approach is effective ceasing of the use of the group key once issued. If the group key is not the primary means of gaining access to the system, or ceasing the ‘master’ private key has the effect of denying access to the encrypted materials the approach may be valid. Designers considering such an approach will have to take account of the problems created by the mobile (or laptop) user who may not reauthenticate to a control system in order to access or interchange information. An alternative approach may be to make use of a forwarding mechanism to provide the key transformations which otherwise would have to take place with the sender. Such a forwarding mechanism would have to control the private group keys and be able to determine members of the group with reference to whatever is the distribution list for the interchange. In services such as E-mail this approach may be acceptable since commonly E-mail interchanges take place through a server mechanism. In other services it is more difficult to comment since the implementations may be more varied, although Web-based services would all pass through one or more servers prior to completion. Workflow systems would be able to use a server-based mechanism since they manage information flows.
Information Security Technical Report, Vol. 5, No. 4
By comparison, pull-based systems for group work will be able to use a server-based transformation system because they can implement an authorization check when a request for information is made. In these environments it is only necessary for group users to have access to the public group keys. This does not protect the system from nongroup members being able to proffer information encrypted for the group, however, the server mechanism will be able to detect these through the failure to match the signature to a member of the group and reject them at that stage.
Summary and Conclusions The PKI environment as currently implemented is not ideal for supporting the concepts of role and group in one-to-many and many-to-many situations. The mechanism restricting the use of a private key to a single entity is essential for satisfying emerging legal controls. However, it creates some practical difficulties where information must be available to wider groups and confidentiality has to be maintained through the overall process. This paper suggests a number of ways in which the current PKI environment could be enhanced in order to provide more commercial applications and commercial implementations.
71