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 valuedocuments for evaluating may still go through the government authority/ agency to be certified/ evalu￾ated, 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 envi￾ronment 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 ap￾proach 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. Accred￾ited 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 architec￾ture, and the number of accredited ECAs is strictly limited/co-coordinated (this helps to enforce non￾competing/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 re￾trieved from the CR by specifying the ECA ID. The ECA’s business details can also be queried by provid￾ing 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 busi￾ness 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 non￾certified 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 no￾Internet access situation is fully supported. • <mobiPolicy/> the MobiPolicy has a similar struc￾ture 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