5.2.1 Barcodes

The barcodes include a range of 1D code systems which are adopted internationally in order to specify object classes for retail shops, industry component production, logistics and storage, to mention some examples. One might wonder why the barcode is relevant to the wireless environment; the answer is straightforward as it represents one‐way near‐field information transfer based on optical readers or imaging, and it also is possible to utilize via scanning via the smart device camera which typically is deployed in all consumer devices. Furthermore, the barcodes can be utilized as a basis for wireless transactions by generating a one‐time code with a limited validity period, to be scanned with a consumer device for the payment transaction. As an example, the payment system security layer may be based on mobile transactions in such a way that the credentials are stored in the cloud and present them in a face‐to‐face merchant environment by using Quick Read (QR) codes, barcodes or Bluetooth. This provides an easy method for low‐value mobile payments as the credentials are not authenticated during the transaction even if the user’s device is physically present at the POS [38].

A QR code is a practical manner to represent data which is related to the object to which it is attached. The barcode is designed for optical machine reading. There are many coding systems in the market that represent the identification of the object, such as the ISBN coding of books. Nowadays, a smart device (or any other device with embedded camera) is able to read the barcode and if it contains information about a web page, the device may enter the respective website. As another example, the IATA‐standardized 2D format of barcodes is utilized in airport boarding via the Bar Coded Boarding Pass (BCBP), or 2D barcodes designed to be presented on a smart device’s display for electronic boarding passes. Figure 5.2 shows an example of the general QR code which can be typically read with smart device applications (generated via Ref. [30]).

The original format of barcode presents the respective data by parallel lines with variable widths and spacing. The 2D‐codes, instead, are based on a matrix presentation of the digitalized contents, defined by ISO/IEC [36]. The forms that the 2D barcode can take include rectangles, dots, hexagons and other geometric patterns which are placed in two dimensions, and a clear safety margin is added around the image. It also typically includes an embedded error correction technique, and the level of the correction can be selected according to the utilized system and need – the principle being that the better protected the image is, less useful data can be presented [37]. In strongly protected images, it is possible to print overlapping artwork on top of the QR code and the contents can still be read without issues. The barcodes have further been developed although the popularity of each advanced variant may not be as widely spread as the previously mentioned ones. The 3D codes are basically 2D variants with an additional parameter such as greyscale or colour palette included to provide an extra variable per pixel that makes it possible to embed more diverse information within the same area as 2D is able to do.

The barcodes are highly secure as they require a close distance for scanning. The potential security breaches of barcodes could be related to the embedded malicious code in the image which may execute a mobile device’s functions without the user’s confirmation or connect to malicious Internet pages which may cause further security issues. If the barcode is used for payment, e.g., via the reception of a promotional code that is presented at the POS upon purchase of the product, the security breach could theoretically be related to someone stealing the barcode and utilizing its value before the original user is able to do so. For that reason, such payments via the barcodes are most suitable in small‐scale purchases such as coffee bars. Nevertheless, it can be argued that for the instantly generated and personalized payment tokens that the customer receives only upon physical presence at the POS, it is highly unlikely that the code would be too easy or even useful for others to exploit.

5.2.2 RFID

RFID is a feasible method for the payment and access. RFID is suitable for various other environments, too, such as asset tracking, race timing and inventory management. RFID forms part of the process for identifying items in a unique way via radio frequencies. It should be noted that NFC is a subset within RFID technology, working on 13.56 MHz frequency. NFC is a secure form of data exchange so that the NFC device may act as an NFC reader as well as an NFC tag, which makes it possible for the NFC device to communicate in a peer‐to‐peer mode [26].

The RFID tag can be active (providing largest coverage areas with their own power source) or passive (basing the power on induction from the reader for short distance). In addition to the tag, the RFID system includes the reader and the antenna as well as the accompanying system. The task of the reader is to send a request to the tag to which the tag responds via the antenna. The active RFID mode provides coverage up to about 100 m which is sufficient for, e.g., a toll road payment system. The range of the passive RFID tags is lower, typically up to about 25 m.

The passive RFID tag operates typically in the Low Frequency (LF) band of 125–134 kHz (with a range of around 10 cm), High Frequency (HF) band of 13.56 MHz (which is also the NFC frequency; providing a range of about 30 cm), and Ultra‐High Frequency (UHF) band of 856–960 MHz (with a range up to around 100 m). Some of the relevant standards for the RFID proximity card and NFC include ISO/IEC 14443, ISO/IEC 18092 and FeliCa. The passive HF RFID tag is also compliant with the ISO/IEC 15693 standard.

The security aspects of proximity cards such as RFID are of high importance for protecting the contents delivery against copying and interception. For the shortest range proximity solutions, the distance as such may protect the transactions although it may be possible to locate an eavesdropping device close to the reader to capture the communications either by placing the respective antenna very near to the device, or by utilizing highly directive antennas.

The RFID and NFC tags are increasingly popular in product posters and signs for delivering compact, additional information like web links to the consumers. In practice, there is a wide selection of commercial, low‐cost mobile RFID readers such as the ones shown in Ref. [22]. They can be paired with devices like smartphones and tablets, and the devices can be used for a variety of business applications. Along with the growth of the consumer smart device and tablet market, the RFID readers are also becoming more popular. The two main available categories are devices that are designed to be attached to mobile devices to convert them into RFID readers, and low‐cost RFID readers for smart devices. These readers support passive UHF EPC Gen 2 protocol, and they can be used for business applications such as access control, authentication and verification, inventory management, logistics and transportation.

As the market develops, it can be more profitable for business users to obtain mobile RFID readers attached to consumer devices compared to conventional handheld RFID readers. Some examples of the enterprise products can be found in Ref. [23] which adds the next generation RFID with 1D and 2D barcode scanning to the mobile devices.

5.2.3 NFC

The components of a typical NFC‐enabled mobile device include SE which can be SIM/UICC, eSE or microSD, as well as NFC controller, NFC chip, protocol stack and CLF. The NFC‐based application such as Mobile Wallet is needed for payments, and a user interface application for the consumer interaction. The communication protocols and interfaces include ISO‐7816, ISO‐14443, SWP, Universal Asynchronous Receiver/Transmitter (UART), I²C, Serial Peripheral Interface (SPI), and NFC needs to be supported by the SE’s operation system such as Java or vendor‐specific OS, and the mobile device’s OS such as Android, iOS, BlackBerry or Windows. Figure 5.3 depicts a typical NFC device architecture.

NFC functions at 13.56 MHz frequency which is the same for the HF‐variant of RFID readers and tags. The NFC equipment can, in fact, work as both reader and tag making it a two‐way technology. Nevertheless, the maximum reading distance is limited to only few centimetres. Typical NFC use cases are related to the information sharing either based on the low‐speed NFC channel, or most typically, via opening a separate bearer such as a Bluetooth transport channel which is triggered by NFC tapping.

The focus of the NFC Forum is on standardizing the application domain. As an example, the data storage standard NFC Data Exchange Format (NDEF) and mapping for tag types are defined by the NFC Forum. It has been decided that the security should be handled on the application layer. The NFC Forum has a separate working group for security that focuses on identifying potential threats and attacks against NFC.

5.2.3.1 Architecture

An NFC Forum device needs to comply with the high level conformance requirements and it implements at least the mandatory parts of the NFC Forum protocol stack and operating modes. The mandatory NFC Forum operating modes are the NFC Forum peer mode and the reader/writer mode. The optional support means that NFC Forum devices may support the NFC Forum card emulation mode. Furthermore, the NFC Forum device can support optional parts of the stack as well as additional protocols and applications that are not defined by the NFC Forum.

An NFC Forum tag can be any contactless component that the NFC Forum device is capable of accessing, as defined by one of the Type X Tag operation specifications. NFC Forum tags are not required to support the complete specification for the NFC Forum protocol stack.

The NFC Forum protocol stack includes the protocols for the communication between NFC Forum devices, between NFC Forum devices and NFC Forum tags, between NFC Forum devices and technology‐compatible contactless smartcards, and optionally between NFC Forum devices and existing reader/writer terminals. It does not make any assumptions about the implementation or the overall architecture of NFC Forum devices.

The NFC Forum protocol stack supports reader/writer, peer and card emulation modes. The NFC Forum reader/writer mode is capable of reading from and writing to NFC Forum tags. In addition, this mode allows the communication with compatible smartcards. The NFC Forum peer mode is meant to communicate with other NFC Forum devices, while the NFC Forum card emulation mode is optional and emulates the behaviour of a smartcard or tag. The communication with existing technology‐compatible reader/writer terminals is possible in this mode.

In the NFC Forum reader/writer mode, the NFC Forum device has the capability to at least communicate with NFC Forum tags. The device can exchange data with NFC Forum tags by NFC Forum or third‐party message formats. The device may also communicate with a variety of components like smartcards, memory cards and tags, provided they are compliant with some of the contactless technology types. The NFC Forum device supports the RF interface variants NFC‐A, NFC‐B and NFC‐F.

In the NFC Forum peer mode, the NFC Forum device has the capability to communicate with another NFC Forum device. The service discovery protocol is the mechanism used to identify the common services supported by both NFC Forum devices.

The NFC Forum card emulation mode allows the NFC Forum device to act as a smartcard or tag in front of a conventional technology‐compatible reader/writer. This mode includes the emulation of memory cards and tags, and the emulation of smartcards is intended mainly for portable devices that can be conveniently presented to reader/writers. Using this mode, existing technology‐compatible terminal infrastructures (e.g., for payment and ticketing) can communicate with NFC Forum devices supporting NFC Forum card emulation mode.

Figure 5.4 depicts the NFC‐defined architecture [7]. The technical architecture contains an initial set of mandatory tag formats based on ISO 14443 Type A, ISO 14443 Type B and Sony’s FeliCa definitions. These include NDEF which specifies a common data format for NFC Forum devices and tags; NFC Record Type Definition (RTD) which specifies standard record types used in messages between NFC Forum devices and between NFC Forum devices and tags; Text RTD which is meant for records containing plain text; Uniform Resource Identifier (URI) RTD which is meant for records referring to an Internet resource; Smart Poster RTD which is meant for posters incorporating tags containing text, audio or other data.

5.2.4 Secure Element

5.2.4.4 Secure Digital Card

In addition to the embedded and UICC‐based secure elements, the third solution is based on a combination of microSD card and NFC antenna that allows the handset to communicate with the contactless readers. The SE can thus be located to the microSD card (or smart microSD as the term is defined by the SD Association) while the handset takes care of the physical NFC functionality. This solution with the SE stored on the microSD card does not depend on the network operator or device manufacturer.

As an example, DeviceFidelity provides a microSD card SE. The company has partnered with Visa on its In2Pay microSD solution to offer NFC payment capabilities across the payWave platform of Visa. DeviceFidelity allows its microSD cards to be issued and personalized like traditional smartcards. It has partnered with Vivotech to add OTA provisioning capabilities to its In2Pay microSD product.

Some of the advantages of the SD‐based SE solution include that it facilitates rapid application deployment and it functions with existing HW. It does not depend on MNOs or device manufacturers, and thus may look attractive for financial institutions as it allows the bank institute that issues the card, to own the SE.

There are two variants of the microSD card‐based NFC solution [27]. The first integrates the NFC antenna and the NFC controller chip (CLF) into the device such as a smart device or wearable device, whereas the SE located in the microSD communicates with the device via the SWP. This variant provides the benefit of reusing the device’s tested and approved interoperable NFC radio technology, and allows easy inserting of the microSD to the card slot of the device while the use of the SE is independent of the MNO. The drawback is that the selection of the devices supporting NFC and SWP – even if the microSD slot is getting more popular – is limited. Figure 5.5 depicts the principle as interpreted from Ref. [27]

The second variant of the microSD‐based NFC device integrates the NFC antenna, chip and SE all integrated into the microSD. This standalone microSD card communicates with the baseband processor of the device via the SD protocol. Figure 5.6 depicts the principle as interpreted from Ref. [27]

5.2.5 Tokenization

The ideas beyond e‐commerce that are based on the SE have resulted in cloud‐based SW solutions. Nevertheless, the drawback of storing confidential credentials outside of the tamper‐resistant UICC or other SE variant, e.g., on the SW of the device and/or on the cloud, creates new challenges for the security. In order not to expose the original payment card information via potential intrusion intentions, one of the solutions is to use tokenization. It refers to hiding the Personal Account Number (PAN) with time‐limited equivalent data, or to a token that is used for payment transactions and that both payer’s device and financial institute can map without others being able to interpret the original information.

It can be argued that tokenization alone would not provide a sufficient security level for mobile payments. The EMVCo specification defines tokenization as an alternate PAN, but, in fact, tokenization does not refer to limited time use of data, it basically replaces the original card information for a longer term. This extended lifetime of the token in current commercial solutions might open doors for potential breaches [8].

The financial institute’s card issuance is quite similar in the SE‐based and in the HCE‐based solutions, the key difference being that the SE environment is static while the HCE is dynamic. As the SE is tamper‐resistant HW, the static approach is adequate for it. However, some of the key questions in the dynamic HCE environment are how the user’s device can be authenticated in a reliable way and how the data is secured within the device. The integrity of the respective application also needs to be ensured, as well as the card data when it is transferred between device and mobile app. Thus, in order to increase the security level, the dynamic management of mobile‐based card issuance needs further on‐device security combined with management ensuring tokens can be transferred to the device in a secure fashion. One method for adding security in this dynamic environment is to evaluate the risk of all the transactions by transmitting additional data from the device such as phone number and device ID. Also the triggering of replenishment of account parameters can be applied, such as device thresholds and Limited Use Keys (LUKs).

The main components of the cloud‐based payment solution are the tokenization system, digital issuance, on‐device HCE client and app management. The role of the tokenization system generates and validates the tokens and serves as a safe token storage while the digital issuance system takes care of the cloud‐based account for the card, the respective keys, card provisioning and replenishment. The task of the app management system is to manage the mobile endpoints and secure card data transfer to devices. Finally, the role of the HCE client is to protect the card‐related data on the device.

It should be noted that the HCE and the SE, even with tokenization, are not mutually exclusive solutions but can be used jointly to create both flexible user experience and achieve a high level of security.

5.3.1 EMV

The EMV Integrated Circuit Card Specifications for Payment Systems are global payment industry definitions that describe the requirements for interoperability between chip‐based consumer payment applications and acceptance terminals in order to enable NFC payment transactions. These specifications are managed by EMVCo.

Named after the original organizations that created the specification, Europay, MasterCard and Visa, the EMV specifications were first published in 1996. According to the statistics of EMVCo, 1 billion active EMV chip cards were used for credit and debit payments in 2010, and 15.4 million EMV‐acceptance terminals deployed around the world.

5.3.2 Google Wallet

The Google Wallet mobile application has been designed to store credit cards and offers of users on their phone hardware, thus it relies on eSE. When shopping at stores that accept Google Wallet, users are able to pay and redeem offers with the same device by tapping the phone at the NFC POS terminal [32].

Google has coordinated partnerships, e.g., with MasterCard, Citi, Sprint and First Data. Google Wallet’s first version works with its Nexus S smartphone equipped with an NFC‐embedded chip, combined with MasterCard PayPass terminals. Google Wallet has been gradually upgraded, and it also supports HCE as of the Android OS version 4.4.

As an example of a forerunner in this field, Google Wallet faced some issues in the early phase as can be interpreted, e.g., from Ref. [33]. According to the source, the PIN for the payment could be revealed by the subject‐matter experts. As precautions, users were advised to refrain from rooting the phone, enable the lock screen, disable the USB debugging, enable full disk encryption and keep the handset SW up to date. It was noted later that the potential issue related solely to rooted devices.

5.3.3 Visa

In February 2012, Visa announced a mobile payment solution to compete with both Google Wallet and at that time the still existing SoftCard payment system. Visa’s solution is based on the Visa‐certified NFC‐equipped smartphone that consumers can use to contact the company and activate the handset for mobile payments. In the solution, the device is linked securely with a user’s bank account. This provides the mobile payments in those locations where Visa’s payWave system is accepted. As is the case in the traditional secure provisioning of payment cards, Visa has extended the idea for mobile technology to securely provision mobile payment accounts OTA [34].

5.3.4 American Express

According to Ref. [35], American Express (AmEx) has a strategy in extending its proprietary payment network to online, mobile and NFC‐based proximity payments space. AmEx, through its Serve platform similar to PayPal, aspires to be broader with a complete solution that integrates mobile payments, loyalty programmes and other social and connected services. AmEx has signed up Sprint and Verizon and its partnership with Payfone allows customers of both Sprint and Verizon to pay using their mobile phone number. The Serve digital wallet service is accepted by many merchants offering AmEx.

5.3.5 Square

According to Ref. [35], Square allows credit cards to be transacted via a mobile phone equipped with a Square reader. As a potential disruptor in the POS market, Square started off at the low end, creating its own market and moving up market to eventually dethrone traditional POS terminals vendors. Nevertheless, Square has no NFC presence so far.

5.3.6 Other Bank Initiatives

Some other bank initiatives are also active in the markets, as summarized in Ref. [35]. Concretely, Bank of America, Wells Fargo and Chase have formed a venture to enable P2P payments for their customers. ClearXChange allows customers to send money to each other without needing to open a separate ClearXChange account. These banks partnered with DeviceFidelity and Visa to use its In2Pay microSD solution to run NFC payment trials across Visa’s payWave platform. These trials indicate that financial institutions are testing the mobile payment schemes with their own mobile payment applications.

5.3.7 Apple Pay

The Apple Pay concept was announced in 2014 to support in‐app purchases and NFC payments at contactless POS terminals which consist of PayWave of Visa, PayPass of MasterCard, and ExpressPay of American Express, and it currently supports a wide variety of credit and debit card banks in the USA. It is an eSE‐based mobile payment wallet service, and applicable for Apple devices of which some models support NFC. Apple Pay is a competitor for previous solutions that other retailers have deployed or planned for mobile payments services, like PayPal, Wal‐Mart, Target, Google Wallet, and the obsolete SoftCard.

Apple Pay relies on single‐use tokens generated by the eSE that replace the transfer of personal debit or credit card number information of the purchaser, combined with two‐factor authentication which refers to fingerprint or button pressing (depending on the device type), as well as on the SE. The financial information of the SE is accessed upon the generation of a dynamic, randomized 16‐digit number during the transaction. The SE is tamper‐resistant and blocks in the case of physical attack intentions.

Apple Pay was initiated with the support of US‐issued payments cards, then UK‐issued payment cards and now one‐factor authentication support is expanding in the international environment. Apple Pay does not relate to chip or PIN/EMV cards, but it is meant to replace credit cards, the device account number and a dynamic security code serving as bank card authorization [7].

5.3.8 Samsung Pay

Samsung Pay was announced in 2015, and is initiated in the US market. The service is supported by Samsung 6 and beyond. It only works on non‐EMV terminals.

5.3.9 MCX

Merchant Customer Exchange (MCX) has been conducting trials of its CurrentC payment system.

5.3.10 Comparison of Wallet Solutions

As can be noted from the previous sections, the mobile payment environment is currently highly fragmented and competitive. Some solutions struggle, some have disappeared from the commercial markets while others have increase their market share.

The mobile payment can be based on NFC or other solutions like cellular connectivity and tokenization with cloud services. Payment can also be based on different variants of SE type, i.e., UICC, eUICC or microSD. Furthermore, there may be cloud‐based solutions relying on, e.g., HCE. Also the tokenization can take place and be combined with many payment schemes with or without SE (the latter providing the highest security level).

In other words, there are many moving parts at the present, from which some work is based on standalone solutions and some on combined SE and SW solutions, while some combinations do not yet exist but are definitely possible (like UICC with tokenization). From trial and error, as the SoftCard initiative has demonstrated, it seems that the essential part of the game is fluent user experience as well as minimal complexity between the infrastructure and service providers. Figure 5.7 summarizes some of the involved items from which the participating entities should select the most optimal one – the task is far from easy.

The following arguments summarize the environment:

• SE provides a high level of security for the payment procedures. In the mobile payment environment, the question is who owns the SE as it also dictates who has overall control of the service.
• HCE removes the need for SE but it results in challenges in securely storing the payment information. Thus, HCE can be combined with other solutions giving a higher level of security, such as tokenization and/or SE (whether UICC or SD based or embedded version). The hybrid model of HCE and SE would provide a highly secure environment.
• UICC‐based SE is typically owned by an MNO who also owns the UICC and thus has control over the business conditions.
• eSE typically lowers the importance of the MNO in the complete picture. The eSE could be owned by the device manufacturer who integrates it to the device during the manufacturing process, although it could also be owned by the chipset manufacturer or the eUICC profile personalization provider. As an example of the current wireless payment environment, in the case of Apple Pay, the eSE is owned by Apple.
• There is also an alternative if NFC is not utilized, the Magnetic Secure Transmission (MST) transaction as Samsung calls it, referring to LoopPay. It basically emulates in a wireless way the magnetic stripe swipe procedure of a credit/debit card at the POS reader.

More information about the comparison of the currently most relevant mobile payment solutions can be found in Ref. [6].

5.4.1 MiFare

The GSMA NFC UICC requirements document [31] details the information for MiFare together with the mobile support. It specifies that the UICC may support MiFare implementation reachable through the MiFare Java Card Host Interface API. In this case, MiFare for the Mobile v2 application framework is required to manage it via OTA. For more information, MiFare for Mobile v2.1 specifications are available in Ref. [28]. Furthermore, the GlobalPlatform Secure Channel Protocol 03 shall be supported as presented in Ref. [29].

There are also competing solutions offered in the commercial markets which may indicate the fragmentation of the transportation ticketing and thus challenges in the wider interoperability. Nevertheless, according to Ref. [16], MiFare is expected to remain in pole position regardless of the advances of its competing alternatives, CiPurse and Calypso.

5.4.2 CiPurse

CiPurse is an alternative to MiFare defined by the Open Standard for Public Transport (OSPT) Alliance. CiPurse refers to an open ticketing standard that enables technology suppliers to develop and deliver interoperable transit fare collection solutions for cards, stickers, fobs, NFC mobile phones and other consumer devices. The cards provide a user‐friendly way to pay for services such as taxi rides or healthcare. A related certification process ensures compatibility of CiPurse products from different suppliers.

Singapore’s Land Transport Authority is one of the first parties that has used CiPurse adaptation [13]. Ref. [18] informs about the first CiPurse‐compliant contactless cards that were issued in Brazil in 2013. Manufactured by Giesecke & Devrient, the cards are based on a CiPurse‐compatible contactless security controller from Infineon Technologies. The CiPurse system has been designed to support flexible and contactless transport and ticketing systems from the start; it also allows the combination of identity and payment functions in mobile devices or multiple application cards. In this specific project, the local system integrator Rede Protege could move its applications to a higher security level and thus increased flexibility and performance using the existing reader infrastructure.

CiPurse cards allow the combination of multiple transport and ticketing applications as well as identity or payment functions on a single card. CiPurse also supports AES 128 encryption algorithm for fast and secure transactions.

5.4.3 Calypso

The GSMA NFC UICC document [31] defines that for Calypso support, the UICC will support both ISO 144443 type A and B specifications. If a Calypso‐based OTA‐downloaded application is present, it needs to comply with the Calypso 3.1 specification. The respective documents are Refs. [14,15].

5.4.4 FeliCa

FeliCa is a solution offered by Sony for mobile payment in different use cases. Like its competitors, it is based on an IC card that is shown over a reader/writer activating the data transmission to rewrite the data to the card. According to Ref. [17], the FeliCa card is suitable for high volumes of transactions and contains a security system. The FeliCa system has achieved ISO/IEC 15408 EAL4/EAL4+ security level, making it a suitable solution for protecting the card balance, e‐money information and personal authentication against malicious attacks. FeliCa can be adapted into a wide variety of environments such as ticketing systems for public transportations, e‐money and residence door keys.

5.5.1 Mobile ID

When the customer utilizes the Internet and logs onto websites, there are typically many kinds of authentication data involved such as usernames and passwords which need to be typed several times. The user cannot ensure their personal data is safe via these methods. The aim of the Mobile ID solution is to simplify online authentication processes by only requiring the user to provide their details once. This data is stored on a protected server hosted by a service provider, making the mobile device the entry point to the web [19].

Mobile Connect is an initiative and standard of GSMA that aims to provide an interoperable and universal login service for everybody worldwide. It eases the global deployment of federated identity via Software‐as‐a‐Service (SaaS) mode. Mobile ID also provides scalable identity management and authentication services for MNOs to act in a digital identity provider role and to set up the Mobile Connect services such as Identity Federation enabling Single Sign On service, onboarding portal services and end‐user permission‐based information‐sharing service, and other services complying with level of assurance up to 4 [20].

5.5.2 Personal Identity Verification

Personal Identity Verification (PIV) refers to an ID chip card issued by a US federal agency. It is able to securely receive, store, recall and send information. The card encrypts data to provide secure communications between the services and the card, while using a common technical and administrative process. The encryption is based on the PKI which complies with federal policies, and is the accepted method of the Global Business Standard for Internet Security. The PKI also provides the procedure for digital signatures to ensure document authenticity. The PIV card thus encrypts data and verifies identity to ensure the confidentiality (only the cardholder can access the data), integrity (only the cardholder may modify the data), authenticity (the origin of the data is guaranteed) and non‐repudiation (leaving no room for falsified data) [21].

5.5.3 Access Systems

Access systems can be based on contact or contactless smartcards as defined in the ISO/EIC 7816 and ISO/EIC 14443 standards. Other methods such as RFID can be applied. The respective card types can thus be utilized for physically opening doors and logically accessing data. There are no restrictions in basing the access to any other wireless means such as mobile communications. In fact, there have been practical solutions in the very early days of GSM for opening garage doors via a cellular call as the A‐subscriber’s MSISDN number indicates the legitimate user. SMS can also be utilized in accessing locations. However, these solutions may be vulnerable to security breaches as the A‐number could be falsified.

As for the related systems and services, basically all the methods used in transport and described earlier in this chapter can be used in the secure access systems.