Pers Ubiquit Comput(2007)11: 157-169 DOI10.1007/s007790060100-9 ORIGINAL ARTICLE MobiPass: a passport for mobile business Robert steele· Will ao eceived: 28 May 2006/ Accepted: 1 August 2006/Published online: 3 November 2006 c Springer-Verlag London Limited 2006 themselves inte potentially vast business opportunity for many industry the fabric of everyday life until they are indistin participants, it also carries challenges along with it. In guishable from it"[1] this paper, a passport-based architecture has been Ubiquitous computing envisions a world embedded proposed to convert this unpredictable, highly dynamic with a vast number of visible or invisible computing pervasive environment into a trusted business plat- artifacts. Ubiquitous computing is producing a pro- form. It utilizes the widely accepted passport concept found effect on the way people use services and here named MobiPass to evaluate and classify the po- information, enabling new types of context aware ser tential mobile entities into a trustworthy form. It allows vices. Ultimately, these technologies will support a fine-grained access control without necessarily having world of ubiquitous commerce [2] had prior interaction with or knowledge of other par- Enormous business opportunities from ubiquitous ties and environments by setting customized rules computing are emerging, from adopted services such as against a MobiPolicy. a detailed case study has been mobile banking to emerging services such as location introduced to demonstrate how the MobiPass archi- based services and remote monitoring services. Ubiq tecture can help customers and retailers to build a uitous computing provides a huge platform to allow trong trusted connection and how the shopping industry participants to catch this"wave experience can be enriched and efficiency improved However, for ubiquitous computing to gain wide- pread adoption and success, certain requirements must be satisfied. One of the major concerns to deter ubiquitous commerce is that currently there is no effective approach to building a trusted environment in 1 Introduct such a highly dy predictable other words there must exist a feasible mechanism to Being regarded as the third wave of the computing protect sensitive information when mobile entities revolution, ubiquitous computing is on the horizon to interact with each other while still allowing the nec permeate modern business and community activities. essary information to be exchanged for useful mobile As it has been stated, the most profound technologies interaction, so as to allow the success of ubiquitous business 3, 4 As ubiquitous computing is based on a massive R. Steele(). W. Tao networked environment with a large population of di Faculty of Information Te University of Technology, verse smart mobile entities, it poses a new challenge P O. Box 123, Broadway, NSw, Australia 2007 from traditional computing. It is hard to know in ad e-mail: steele @it. uts. edu.au vance which entities will be interacted with and a re- quest can come from unknown environments or e-mail: wtao@@it.uts. edu.au entities where holistic information is not available [5
ORIGINAL ARTICLE MobiPass: a passport for mobile business Robert Steele Æ Will Tao Received: 28 May 2006 / Accepted: 1 August 2006 / Published online: 3 November 2006 Springer-Verlag London Limited 2006 Abstract While pervasive computing provides a potentially vast business opportunity for many industry participants, it also carries challenges along with it. In this paper, a passport-based architecture has been proposed to convert this unpredictable, highly dynamic pervasive environment into a trusted business platform. It utilizes the widely accepted passport concept here named MobiPass to evaluate and classify the potential mobile entities into a trustworthy form. It allows fine-grained access control without necessarily having had prior interaction with or knowledge of other parties and environments by setting customized rules against a MobiPolicy. A detailed case study has been introduced to demonstrate how the MobiPass architecture can help customers and retailers to build a strong trusted connection and how the shopping experience can be enriched and efficiency improved. 1 Introduction Being regarded as the third wave of the computing revolution, ubiquitous computing is on the horizon to permeate modern business and community activities. As it has been stated, ‘‘the most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it’’ [1]. Ubiquitous computing envisions a world embedded with a vast number of visible or invisible computing artifacts. Ubiquitous computing is producing a profound effect on the way people use services and information, enabling new types of context aware services. Ultimately, these technologies will support a world of ubiquitous commerce [2]. Enormous business opportunities from ubiquitous computing are emerging, from adopted services such as mobile banking to emerging services such as locationbased services and remote monitoring services. Ubiquitous computing provides a huge platform to allow industry participants to catch this ‘‘wave’’. However, for ubiquitous computing to gain widespread adoption and success, certain requirements must be satisfied. One of the major concerns to deter ubiquitous commerce is that currently there is no effective approach to building a trusted environment in such a highly dynamic, unpredictable environment; in other words, there must exist a feasible mechanism to protect sensitive information when mobile entities interact with each other while still allowing the necessary information to be exchanged for useful mobile interaction, so as to allow the success of ubiquitous business [3, 4]. As ubiquitous computing is based on a massive networked environment with a large population of diverse smart mobile entities, it poses a new challenge from traditional computing. It is hard to know in advance which entities will be interacted with and a request can come from unknown environments or entities where holistic information is not available [5, R. Steele (&) W. Tao Faculty of Information Technology, University of Technology, Sydney, P.O. Box 123, Broadway, NSW, Australia 2007 e-mail: rsteele@it.uts.edu.au W. Tao e-mail: wtao@it.uts.edu.au 123 Pers Ubiquit Comput (2007) 11:157–169 DOI 10.1007/s00779-006-0100-9
Pers Ubiquit Comput(2007)11: 157-169 6]. In this decentralized infrastructure, the mobile en- The most significant difference in ubiquitous com tity might have to make autonomous decisions with puting from traditional mainframe and personal com ly limited information available. All these aspects puting is that the environment and network is introduce the new issue which is trustworthiness in unpredictable and keeps changing. The biggest chal ubiquitous business computing. This issue is regarded lenge is that the mobile entity does not know which as the greatest barrier which may stop ubiquitous entity is trustworthy, including previously un-encoun computing success in the longer-term [7-9. Previous tered entities. However, here, we claim that the mobile studies show that trust plays a critical role in customer user usually will have a rough idea about which ser elations [10 and the importance of trust has also been vices they want to use and which group of entities they examined for e Commerce [11, 12] and mCommerce would like to interact with. So here we use the well known and proven passport concept, here migrated to In this paper, we propose an architecture named a mechanism to allow dynamic authentication and bipAss to build a trusted and flexible environment authorization, to convert this unpredictability into a for ubiquitous business computing. Our architecture predictable, trusted form aims to allow transaction entities to create trusted The new architecture is based on extending digital interaction without necessarily having prior knowledge certificate technologies of each other. By employing our architecture, mobile entities can interact safely with each other by enabling 2.2 Overview of the mobiPass architecture pre-set customized preferences. Our architecture adopts a user centric philosophy that delegates the final The infrastructure of the architecture utilizes a number decision to the user, still with reasonable flexibility and of existing technologies such as digital certificates, extensibility In our architecture, the mobile entity only certificate authorities (CAs)and asymmetric key talks with another trusted entity/environment which satisfies this customized access control rules encryption. There is some virtue in reusing existing This paper is structured as follows. Section 2 de- technology building blocks in the infrastructure of scribes the overall architecture of mobipass and mobile computing, as a large number of devices are interactions between different elements for establish already in the field. If the architecture is to build on top ing the trusted environment in mobile business com of existing and well-proven technologies, it can be puting. In Sect. 3, a representative case study is used to easily adopted and implemented The new elements introduced in this architecture to demonstrate our architecture. Section 4 discusses re- enable the specific MobiPass functionality are as fol lated work and Sect. 5 concludes the pape lows. Central Registry (not mandatory) 2 MobiPass architecture MobiPolicy Extended Certificate Authority(ECA) 2.1 Motivation Mobipass · Mobimanager As we have emphasized, to pursue success in ubiqui tous/mobile business a trusted environment must be All the new elements are shown in Fig. 1, and the established via a practical approach. As mobile com- following sections discuss how these elements inter puting is a user-centric business model. the approach operate to create a flexible and trusted mobile business for creating a trusted network must be straightforward platform. The architecture will be addressed as follows. Firstly, generally describe the elements in the and easily adoptable by end users and it must provide architecture respectively, and then we explain how fine-grained access control with an easily operable user these elements can establish the trusted mobile should not be exposed directly to the end user. In our other ht, i.e., how these elements interact with architecture, we have considered both technical factors and human factors and utilized the well-known pass- port concept combined with a preference wizard to 2.2. 1 Central registry allow users to easily set their customized rules to de cide which service they want to use and which trans- The central registry( CR) is a global, trusted service action entities they want to interact with in a flexible registry in our architecture. The purpose of introducing and understandable way the Cr into our architecture is to provide a solid base Spr
6]. In this decentralized infrastructure, the mobile entity might have to make autonomous decisions with only limited information available. All these aspects introduce the new issue which is trustworthiness in ubiquitous business computing. This issue is regarded as the greatest barrier which may stop ubiquitous computing success in the longer-term [7–9]. Previous studies show that trust plays a critical role in customer relations [10] and the importance of trust has also been examined for eCommerce [11, 12] and mCommerce [13, 14]. In this paper, we propose an architecture named MobiPass to build a trusted and flexible environment for ubiquitous business computing. Our architecture aims to allow transaction entities to create trusted interaction without necessarily having prior knowledge of each other. By employing our architecture, mobile entities can interact safely with each other by enabling pre-set customized preferences. Our architecture adopts a user centric philosophy that delegates the final decision to the user, still with reasonable flexibility and extensibility. In our architecture, the mobile entity only talks with another trusted entity/environment which satisfies this customized access control rules. This paper is structured as follows. Section 2 describes the overall architecture of MobiPass and interactions between different elements for establishing the trusted environment in mobile business computing. In Sect. 3, a representative case study is used to demonstrate our architecture. Section 4 discusses related work and Sect. 5 concludes the paper. 2 MobiPass architecture 2.1 Motivation As we have emphasized, to pursue success in ubiquitous/mobile business, a trusted environment must be established via a practical approach. As mobile computing is a user-centric business model, the approach for creating a trusted network must be straightforward and easily adoptable by end users and it must provide fine-grained access control with an easily operable user interface. For example, complex security protocols should not be exposed directly to the end user. In our architecture, we have considered both technical factors and human factors and utilized the well-known passport concept combined with a preference wizard to allow users to easily set their customized rules to decide which service they want to use and which transaction entities they want to interact with in a flexible and understandable way. The most significant difference in ubiquitous computing from traditional mainframe and personal computing is that the environment and network is unpredictable and keeps changing. The biggest challenge is that the mobile entity does not know which entity is trustworthy, including previously un-encountered entities. However, here, we claim that the mobile user usually will have a rough idea about which services they want to use and which group of entities they would like to interact with. So here we use the well known and proven passport concept, here migrated to a mechanism to allow dynamic authentication and authorization, to convert this unpredictability into a predictable, trusted form. The new architecture is based on extending digital certificate technologies. 2.2 Overview of the MobiPass architecture The infrastructure of the architecture utilizes a number of existing technologies such as digital certificates, certificate authorities (CAs) and asymmetric key encryption. There is some virtue in reusing existing technology building blocks in the infrastructure of mobile computing, as a large number of devices are already in the field. If the architecture is to build on top of existing and well-proven technologies, it can be easily adopted and implemented. The new elements introduced in this architecture to enable the specific MobiPass functionality are as follows: • Central Registry (not mandatory) • MobiPolicy • Extended Certificate Authority (ECA) • MobiPass • MobiManager All the new elements are shown in Fig. 1, and the following sections discuss how these elements interoperate to create a flexible and trusted mobile business platform. The architecture will be addressed as follows. Firstly, we generally describe the elements in the architecture respectively, and then we explain how these elements can establish the trusted mobile environment, i.e., how these elements interact with each other. 2.2.1 Central registry The central registry (CR) is a global, trusted service registry in our architecture. The purpose of introducing the CR into our architecture is to provide a solid base 158 Pers Ubiquit Comput (2007) 11:157–169 123
Pers Ubiquit Comput(2007)11: 157-169 Fig. 1 The overall MobiPass A ECA Mobile phone . m MobiManager Requestor MobiManager reference for our trusted infrastructure, although it is 2.2.2 MobiPolicy not mandatory in the architecture The Cr has responsibility for several issues MobiPolicy allows a flexible and extensible approach Accrediting of an ECA, assigning the unique Id to to describing the particular service and evaluating an ECA (ECA-ID), and providing the interface to mobile entities based on their backgrounds and other allow a mobile entity to pull the ECAs public key. related information for this particular service. It is a and check the relevant details of an eca service oriented description schema which is used to Allowing organizations to register their MobiPoli- depict how and which mobile entities will interact with cies, assign the unique ID to the MobiPolicy each other for this service. Different services will ha different mobiPolicies and which information the (Policy-ID), and provide the interface to allow a mobile entity to pull the schema( description)of the MobiPolicy needs to describe it is entirely based on the Mobipolicy characteristic of the service An Xml schema is used to describe the detailed The detailed interaction between the CR and mobile data structure of each MobiPolicy, and each Mobi entities will be discussed shortly. We recognize that Policy will have a globally unique ID, a service building a trusted environment in ubiquitous/mobile describing section and the mobile entity (service computing requires more than an enabling technical description) describing section. It can either infrastructure alone. Law, legislation and social norms signed with a globally unique id by the Cr or be self- [17, 15] are also needed to establish a working trustworthy assigned with an ID in a certain range. Due to the system. For example, the operation of the Cr will be complexity of real business services and the differences dministered by a trusted third party, e. g, a government between service providers, XML schema is a good authority. For practical reasons, we choose a geograph- candidate for constraining the data structure ical domain-based architecture to implement this CR The awareness/scope of MobiPolici SCs This means the word central in here is a logical concept, able. This means the policies can be published by, e.g and the physical architecture of the CR is decentralized international standard bodies and recognized globally and self-regulated. It uses a URI to indicate/represent or be published by an individual person and shared trustworthiness. For instance, we can say that the root with friends. The reason to allow flexibility and scala- trusted URI for the Cr is mobipass. org, so all ECAs bility with MobiPolicies is that ubiquitous computing which operate in Paramatta, Australia can, e. g, be listed can be used for multitudinous purposes and indus- at city state country. mobipass org and managed by, e. g, tries--it is almost impossible to finalize with a rigid the"Local City Mobile Service Authority framework how to use all ubiquitous services. We
reference for our trusted infrastructure, although it is not mandatory in the architecture. The CR has responsibility for several issues: • Accrediting of an ECA, assigning the unique ID to an ECA (ECA-ID), and providing the interface to allow a mobile entity to pull the ECA’s public key, and check the relevant details of an ECA. • Allowing organizations to register their MobiPolicies, assign the unique ID to the MobiPolicy (Policy-ID), and provide the interface to allow a mobile entity to pull the schema (description) of the MobiPolicy. The detailed interaction between the CR and mobile entities will be discussed shortly. We recognize that building a trusted environment in ubiquitous/mobile computing requires more than an enabling technical infrastructure alone. Law, legislation and social norms [7, 15] are also needed to establish a working trustworthy system. For example, the operation of the CR will be administered by a trusted third party, e.g., a government authority. For practical reasons, we choose a geographical domain-based architecture to implement this CR. This means the word central in here is a logical concept, and the physical architecture of the CR is decentralized and self-regulated. It uses a URI to indicate/represent trustworthiness. For instance, we can say that the root trusted URI for the CR is mobipass.org, so all ECAs which operate in Paramatta, Australia can, e.g., be listed at city.state.country.mobipass.org and managed by, e.g., the ‘‘Local City Mobile Service Authority’’. 2.2.2 MobiPolicy MobiPolicy allows a flexible and extensible approach to describing the particular service and evaluating mobile entities based on their backgrounds and other related information for this particular service. It is a service oriented description schema which is used to depict how and which mobile entities will interact with each other for this service. Different services will have different MobiPolicies and which information the MobiPolicy needs to describe it is entirely based on the characteristic of the service. An XML Schema is used to describe the detailed data structure of each MobiPolicy, and each MobiPolicy will have a globally unique ID, a service describing section and the mobile entity (service description) describing section. It can either be assigned with a globally unique ID by the CR or be selfassigned with an ID in a certain range. Due to the complexity of real business services and the differences between service providers, XML schema is a good candidate for constraining the data structure. The awareness/scope of MobiPolicies is very scalable. This means the policies can be published by, e.g., international standard bodies and recognized globally, or be published by an individual person and shared with friends. The reason to allow flexibility and scalability with MobiPolicies is that ubiquitous computing can be used for multitudinous purposes and industries—it is almost impossible to finalize with a rigid framework how to use all ubiquitous services. We Fig. 1 The overall MobiPass architecture Pers Ubiquit Comput (2007) 11:157–169 159 123
160 Pers Ubiquit Comput(2007)11: 157-169 recognize this diversity and try to make our architec- Policy.lD_(2 bit digitals) ture open and extensible enough A MobiPolicy uses customized criteria to enable it Reversed Block (issued (I bits to produce a fine-grained evaluation result. For in- SelfUsing block [1 (I bits) stance, a MobiPolicy published by the National Accommodation association will have one section for describing the attributes for real estate agents, and Fig. 2 Policy ID allocation another sections for describing properties such as their type, the number of bed rooms, location etc. For an example"Friend-Finder"service, the service provider self-using Policy-IDs Non-collision is assured for Pol can publish a MobiPolicy which tries to describe the icy-IDs from the reserved block person who subscribes to the service. For example, the The purpose of the Policy-ID is that it allows the name, gender, nationality and some other service re- user (or his/her MobiManager)to recognize which lated attributes could be described in the Friend-Fin- service an incoming MobiPass is related to By check der MobiPolicy. It is important to note that a ing the Policy-ID, it enables the MobiManager to MobiPolicy to govern mobile interactions with an recognize and discard and/ or process all different individual could equally well not contain personally types of MobiPasses identifying information, e.g., only their shopping By having this specific standard for incoming infor- interests or other preferences, enabling privacy main- mation to a mobile user, describing the unpredicted taining mobile interactions. environment and surrounding entities, if this informa In theory, any organization (person) can publish tion can also be authoritatively certified, the mobile their MobiPolicies, there is no technical barrier to de- entity can trust other entities which present the certi ter the organization (person) to publish their own fied evaluation results, even a previously unseen mo- MobiPolicy. For instance, either the Australian Taxa- bile entity, based on the particular required tion Office(ATO) or Paramatta Football Club can characteristics of the entity that have been certified publish their own specific MobiPolicy to describe their For example, by employing the standard for describing ervice and which mobile entities will be involved in a furniture shop, when the mobile entity receives the their services. This is absolutely acceptable and feasi- message formatted in accordance with a MobiPolicy ble in the technical sense. The reason to enable this is for a shop-finder service, it can easily have a quickly to meet the maximum flexibility and scalability in our attained and trusted idea of the seller and its business architecture Due to the pre-defined standard that a MobiPolicy In terms of practical concerns (related to end user represents, requestees will be able to design custom- Acceptance), although there is no limitation about the ized rules in advance through their knowledge of the publishing ability of MobiPolicies, it is surmised that criteria provided by a MobiPolicy sually market forces would push the similar services to be merged and form a more general and commonly 2.2.3 Extended certificate authority usable MobiPolicy, shared in by a larger user set/ market As the name suggests, the ECa is a functionally ex- 6 The Policy-ID is very important in our architecture tended CA Beyond issuing the digital certificate, it can because it allows for the reuse, recognizing and man- also evaluate the mobile entities according to the mo- aging of the MobiPolicy. It is a globally unique 32 bit biPolicy, and digitally sign the results of the evaluation digital number. The Policy-ID range has two blocks, In our architecture, the eCa is a trusted third party which are the reserved block and self-using block. IDs Trust is(partially) delegated to the ECA, and the with the first digit a 0 belong to the reserved block and output produced by the ECa is the MobiPass. The the remainder of IDs are in the self-using block ECA is the connector which links the potentially (Fig. 2). The Policy-ID in the reserved range can be communicating but untrusted entities into a scalable only assigned by the Cr. If a MobiPolicy is created by and safe network. someone who does not want it to be registered in the The ECA can be the MobiPolicy publisher or the CR(e.g, a MobiPolicy shared with a few friends), a third party who is asked to certify the related business self-using block is available. Generally, random 32-bit entities and activities. It can vary according to the de numbers are chosen to work as the Policy-ID. As the gree of trustworthiness needed in the service. Or in set of available numbers is relatively large, it mitigates some scenarios, the ECA might not have the real against, (but not totally eliminates) the collision of the authority to evaluate mobile entities and all relevant Spr
recognize this diversity and try to make our architecture open and extensible enough. A MobiPolicy uses customized criteria to enable it to produce a fine-grained evaluation result. For instance, a MobiPolicy published by the National Accommodation Association, will have one section for describing the attributes for real estate agents, and another sections for describing properties such as their type, the number of bed rooms, location etc. For an example ‘‘Friend-Finder’’ service, the service provider can publish a MobiPolicy which tries to describe the person who subscribes to the service. For example, the name, gender, nationality and some other service related attributes could be described in the Friend-Finder MobiPolicy. It is important to note that a MobiPolicy to govern mobile interactions with an individual could equally well not contain personally identifying information, e.g., only their shopping interests or other preferences, enabling privacy maintaining mobile interactions. In theory, any organization (person) can publish their MobiPolicies, there is no technical barrier to deter the organization (person) to publish their own MobiPolicy. For instance, either the Australian Taxation Office (ATO) or Paramatta Football Club can publish their own specific MobiPolicy to describe their service and which mobile entities will be involved in their services. This is absolutely acceptable and feasible in the technical sense. The reason to enable this is to meet the maximum flexibility and scalability in our architecture. In terms of practical concerns (related to end user acceptance), although there is no limitation about the publishing ability of MobiPolicies, it is surmised that usually market forces would push the similar services to be merged and form a more general and commonly usable MobiPolicy, shared in by a larger user set/ market. The Policy-ID is very important in our architecture because it allows for the reuse, recognizing and managing of the MobiPolicy. It is a globally unique 32 bit digital number. The Policy-ID range has two blocks, which are the reserved block and self-using block. IDs with the first digit a 0 belong to the reserved block and the remainder of IDs are in the self-using block (Fig. 2). The Policy-ID in the reserved range can be only assigned by the CR. If a MobiPolicy is created by someone who does not want it to be registered in the CR (e.g., a MobiPolicy shared with a few friends), a self-using block is available. Generally, random 32-bit numbers are chosen to work as the Policy-ID. As the set of available numbers is relatively large, it mitigates against, (but not totally eliminates) the collision of the self-using Policy-IDs. Non-collision is assured for Policy-IDs from the reserved block. The purpose of the Policy-ID is that it allows the user (or his/her MobiManager) to recognize which service an incoming MobiPass is related to. By checking the Policy-ID, it enables the MobiManager to recognize and discard and/ or process all different types of MobiPasses. By having this specific standard for incoming information to a mobile user, describing the unpredicted environment and surrounding entities, if this information can also be authoritatively certified, the mobile entity can trust other entities which present the certi- fied evaluation results, even a previously unseen mobile entity, based on the particular required characteristics of the entity that have been certified. For example, by employing the standard for describing a furniture shop, when the mobile entity receives the message formatted in accordance with a MobiPolicy for a shop-finder service, it can easily have a quickly attained and trusted idea of the seller and its business. Due to the pre-defined standard that a MobiPolicy represents, requestees will be able to design customized rules in advance through their knowledge of the criteria provided by a MobiPolicy. 2.2.3 Extended certificate authority As the name suggests, the ECA is a functionally extended CA. Beyond issuing the digital certificate, it can also evaluate the mobile entities according to the MobiPolicy, and digitally sign the results of the evaluation. In our architecture, the ECA is a trusted third party. Trust is (partially) delegated to the ECA, and the output produced by the ECA is the MobiPass. The ECA is the connector which links the potentially communicating but untrusted entities into a scalable and safe network. The ECA can be the MobiPolicy publisher or the third party who is asked to certify the related business entities and activities. It can vary according to the degree of trustworthiness needed in the service. Or in some scenarios, the ECA might not have the real authority to evaluate mobile entities and all relevant Policy-ID (32 bit digitals) Reversed Block (issued by CR) [0]…. …. …. …. (31 bits) Self-Using Block [1]…. … …. ….. (31 bits) Fig. 2 Policy ID allocation 160 Pers Ubiquit Comput (2007) 11:157–169 123
Pers Ubiquit Comput(2007)11: 157-169 documents for evaluating may still go through the MobiPolicy. It contains the real data describing a government authority/ agency to be certified/ evalu- particular mobile entity in relation to a certain service ated, then mobile entities would bring these hard For instance, if the MobiPolicy is used to describe copies to the ECA. After checking these"stamped" which business entities will use a location-based service documents, the ECA represents the evaluation results to promote their products, the data in the mobiPass in signed electronic form according to the MobiPolicy. can provide a signed description of a particular busi The digitally signed output using the ECA's private ness entity such as the registration time of the business key is the mobiPass entity and the self-description of the business entity As we discussed, it is hard to build a trusted envi- Here is the general structure of the MobiPass, all ronment based only on technological features. For contents in the certified elements need to be certified practical concerns, in here, we assume ECAs can be by the ECA such as the business profile and the maybe there is also the potential for a different ap- certifier tit categorized into three main types: (in the real case, mobile entity(service provider ),'s public key, and non content can be put into the non-Certified proach to arranging ECA elements as extra description such as the price they credited ECA sell the particular model of sofa at, at that particular time Registered ECA · UnRegistered ECA There are five dedicated elements in the mobipass to ensure trustworthiness The structure is shown in the All ECAs are supposed to have a unique ECA-ID. Fig 3 An ECA-ID has a similar structure with the Policy-ID 32 bits long with reserved and self-using blocks. The <eca/> the eca element has two sub elements which are eca and ecalocation which contains the accredited ECA usually are highly trusted third parties, such as the Justice Department and the Fair Trading ID of the ECA(ECA-ID)and the URI from which Association, and are registered with the Cr. Accred you can obtain the ECA's public key. The protocol ited ECAs perform the similar duty as they do for to retrieve the public key of the eCa is included as current real businesses, such as issuing the permission well. In here, cr:// means the public key resides or to trade suspending a license if a rule is breached etc the Cr. also, for a non-registered ECA, it is In our architecture, the MobiPass issued by an possible to get the public key by short-range Accredited ECA should be fully trusted. Following the wireless, such as bt: // Bluetooth. The protocol for structure of the cr. the accredited eca is structured retrieving should be very flexible and the no- according to a geographical domain-based architec Internet access situation is fully supported. ture, and the number of accredited ECAs is strictly <mobiPolicy/> the MobiPolicy has a similar struc- limited/co-coordinated (this helps to enforce non ture with the <eca/> element. with Id and the competing/non-overlapping MobiPolicies for given location to retrieve the schema. Also, the protocol domains in given geographical areas) to retrieve the schema is fexible The Registered ECA means the eCA itself has been <certifiedDigest/> this element is used to store the xamined by the Cr, and certain business information digitally signed digest value by the ECA. It is used has been verified, such as business name business for checking the integrity/ non-corruption of the registration date and business description. Both content in the certified obiPass element. such as the public key of the service provider. accredited and registered ECAs will be assigned a. kmobiPass Digest/> to ensure the authentication, a unique number from the reserved block, and the public key of the accredited and registered ECA can be re- <mobiPassDigest/>: this element is used for storing trieved from the CR by specifying the ECA ID. The the whole mobiPass digest value. And it is digitally ECAs business details can also be queried by provid signed by the service provider itself. This means ing the ECA-ID to the Cr. A non-registered ECA can <certifiedDigest/> element is used for ensuring the only pick a number from the self-using block, and the public key of the service provider is true, and the public key cannot be stored in the Cr <mobiPass Digest/> element is used for ensuring the MobiPass is sent by this particular service provider. <timestamp/> the timestamp element is used to 2. 2. 4 MobiPass indicate the time frame the mobiPass lives and the value of <not Before/> and <not After> will be A MobiPass is described by XML which complies signed by the sender's public key. This is used to with the corresponding XML schema represented prevent man-in-middle attack. The difference value
documents for evaluating may still go through the government authority/ agency to be certified/ evaluated, then mobile entities would bring these hard copies to the ECA. After checking these ‘‘stamped’’ documents, the ECA represents the evaluation results in signed electronic form according to the MobiPolicy. The digitally signed output using the ECA’s private key is the MobiPass. As we discussed, it is hard to build a trusted environment based only on technological features. For practical concerns, in here, we assume ECAs can be categorized into three main types: (in the real case, maybe there is also the potential for a different approach to arranging ECAs) • Accredited ECA • Registered ECA • UnRegistered ECA All ECAs are supposed to have a unique ECA-ID. An ECA-ID has a similar structure with the Policy-ID; 32 bits long with reserved and self-using blocks. The accredited ECA usually are highly trusted third parties, such as the Justice Department and the Fair Trading Association, and are registered with the CR. Accredited ECAs perform the similar duty as they do for current real businesses, such as issuing the permission to trade, suspending a license if a rule is breached etc. In our architecture, the MobiPass issued by an Accredited ECA should be fully trusted. Following the structure of the CR, the accredited ECA is structured according to a geographical domain-based architecture, and the number of accredited ECAs is strictly limited/co-coordinated (this helps to enforce noncompeting/non-overlapping MobiPolicies for given domains in given geographical areas). The Registered ECA means the ECA itself has been examined by the CR, and certain business information has been verified, such as business name, business registration date and business description. Both accredited and registered ECAs will be assigned a unique number from the reserved block, and the public key of the accredited and registered ECA can be retrieved from the CR by specifying the ECA ID. The ECA’s business details can also be queried by providing the ECA-ID to the CR. A non-registered ECA can only pick a number from the self-using block, and the public key cannot be stored in the CR. 2.2.4 MobiPass A MobiPass is described by XML which complies with the corresponding XML schema represented MobiPolicy. It contains the real data describing a particular mobile entity in relation to a certain service. For instance, if the MobiPolicy is used to describe which business entities will use a location-based service to promote their products, the data in the MobiPass can provide a signed description of a particular business entity such as the registration time of the business entity and the self-description of the business entity Here is the general structure of the MobiPass, all contents in the certified elements need to be certified by the ECA such as the business profile and the mobile entity (service provider)’s public key, and noncertified content can be put into the non-Certified elements as extra description such as the price they sell the particular model of sofa at, at that particular time. There are five dedicated elements in the MobiPass to ensure trustworthiness. The structure is shown in the Fig. 3. • <eca/> the ECA element has two sub elements, which are eca and ecaLocation, which contains the ID of the ECA(ECA-ID) and the URI from which you can obtain the ECA’s public key. The protocol to retrieve the public key of the ECA is included as well. In here, cr:// means the public key resides on the CR. Also, for a non-registered ECA, it is possible to get the public key by short-range wireless, such as bt://, Bluetooth. The protocol for retrieving should be very flexible and the noInternet access situation is fully supported. • <mobiPolicy/> the MobiPolicy has a similar structure with the <eca/> element, with ID and the location to retrieve the schema. Also, the protocol to retrieve the schema is flexible. • <certifiedDigest/> this element is used to store the digitally signed digest value by the ECA. It is used for checking the integrity/ non-corruption of the content in the certified MobiPass element, such as the public key of the service provider. • <mobiPassDigest/> to ensure the authentication, a <mobiPassDigest/>: this element is used for storing the whole mobiPass digest value. And it is digitally signed by the service provider itself. This means <certifiedDigest/> element is used for ensuring the public key of the service provider is true, and the <mobiPassDigest/> element is used for ensuring the MobiPass is sent by this particular service provider. • <timestamp/> the timestamp element is used to indicate the time frame the MobiPass lives. And the value of <notBefore/> and <notAfter> will be signed by the sender’s public key. This is used to prevent man-in-middle attack. The difference value Pers Ubiquit Comput (2007) 11:157–169 161 123