aviation credential interoperability solution (acis) technical

This document is a staff-level concept. It represents work towards specifications that Transportation Security Administration may use as a basis for future standards for biometric access controls at airports. This document is not an exhaustive discussion of the subject of biometric access controls and does not necessarily represent the consolidated views of TSA or others in the Executive Branch review process. However, the document sets forth concepts that are generally accepted in the pertinent expert communities as good practices to advance the integrity of access control systems, identity verification, and security. We invite comment on any aspect of the document, by contacting [email protected].

Aviation Credential Interoperability Solution

(ACIS) Technical Specification

Version 1.0.2 February 27, 2008

ACIS Draft Technical Specification Version 1.0.2

February 27, 2008

Page ii

Table of Contents H1 INTRODUCTION............................................................................................................................................. ��H1

�H1.1 PURPOSE..................................................................................................................................................... ��H1 �H1.2 SCOPE......................................................................................................................................................... ��H1 �H1.3 ACIS PROGRAM OVERVIEW....................................................................................................................... ��H2 �H1.4 REFERENCES .............................................................................................................................................. ��H3 �H1.5 APPLICABLE GOVERNMENT REGULATIONS ................................................................................................ ��H3 �H1.6 GLOSSARY OF TERMS................................................................................................................................. ��H4 �H1.7 ACRONYMS AND ABBREVIATIONS.............................................................................................................. ��H8

�H2 ACIS CONCEPTS .......................................................................................................................................... ��H11 �H2.1 IDENTITY VERSUS PRIVILEGE................................................................................................................... ��H11

��H2.1.1 Identity-Based Access Control............................................................................................................ ��H13 ��H2.1.2 Privilege-Based Access Control ......................................................................................................... ��H15

��H2.2 LOCAL EMPLOYEES VERSUS TRANSIENT EMPLOYEES ............................................................................. ��H17 ��H2.3 CENTRALIZED VERSUS DISTRIBUTED SYSTEM CONCEPTS ....................................................................... ��H17 ��H2.4 LEVERAGING PIV AND EXISTING TSA CREDENTIALING PROGRAMS ....................................................... ��H18 ��H2.5 ACIS PHASED IMPLEMENTATION............................................................................................................. ��H19

��H2.5.1 ACIS Phase I – ACIS Identity Credential ........................................................................................... ��H19 ��H2.5.2 ACIS Phase II – ACIS Electronic Identity Verification....................................................................... ��H21 ��H2.5.3 ACIS Phase III - ACIS Privilege Credential ....................................................................................... ��H22 ��H2.5.4 Summary of ACIS Phases and Credential Deployment ...................................................................... ��H23

��H3 ACIS SYSTEM OVERVIEW ........................................................................................................................ ��H25 ��H3.1 ACIS PARTICIPATING ENTITIES ............................................................................................................... ��H26

��H3.1.1 ACIS Aviation Sector Entities ............................................................................................................. ��H26 ��H3.1.2 ACIS Federal Entities ......................................................................................................................... ��H28 ��H3.1.3 Non-ACIS Credential Issuers.............................................................................................................. ��H28

��H3.2 ACIS SYSTEM ROLES............................................................................................................................... ��H30 ��H3.3 ACIS AVIATION SECTOR ROLES .............................................................................................................. ��H30

��H3.3.1 ACIS Sponsor...................................................................................................................................... ��H31 ��H3.3.2 ACIS Applicant ................................................................................................................................... ��H31 ��H3.3.3 ACIS Participant................................................................................................................................. ��H32 ��H3.3.4 ACIS Agent.......................................................................................................................................... ��H32 ��H3.3.5 ACIS Identity Authority Roles............................................................................................................. ��H33 ��H3.3.6 Access Control Authority Roles .......................................................................................................... ��H36

��H3.4 TSA ACIS PROGRAM FEDERAL ROLES.................................................................................................... ��H38 ��H3.4.1 ACIS Compliance Authority................................................................................................................ ��H38 ��H3.4.2 ACIS Central Status Provider............................................................................................................. ��H39 ��H3.4.3 ACIS Certificate Authority Provider................................................................................................... ��H40

��H3.5 ACIS SYSTEM ELEMENTS ........................................................................................................................ ��H41 ��H3.5.1 ACIS Credential Issuance System Elements ....................................................................................... ��H41 ��H3.5.2 ACIS Access Control System Elements ............................................................................................... ��H44 ��H3.5.3 ACIS Central Service Provider System Elements ............................................................................... ��H47

��H4 ACIS CHAIN OF TRUST.............................................................................................................................. ��H50 ��H4.1 ACIS PKI CHAIN OF TRUST ..................................................................................................................... ��H50

��H4.1.1 TSA ACIS Root CA.............................................................................................................................. ��H50 ��H4.1.2 ACIS Identity Authority Subordinate CA ............................................................................................ ��H51

��H4.2 ACIS LINKAGE OF REVOCABLE ELEMENTS ............................................................................................. ��H52 ��H4.2.1 ACIS CSMS Index ............................................................................................................................... ��H52


February 27, 2008

Page iii

��H4.2.2 ACIS Person Identifier........................................................................................................................ ��H54 ��H4.2.3 ACIS Credential Identifier .................................................................................................................. ��H54 ��H4.2.4 PACS Privilege Identifier ................................................................................................................... ��H54 ��H4.2.5 Privacy Protection in the ACIS Trust Chain....................................................................................... ��H55

��H5 ACIS SECURITY AND PRIVACY............................................................................................................... ��H56 ��H5.1 SYSTEM SECURITY ................................................................................................................................... ��H56 ��H5.2 PRIVACY................................................................................................................................................... ��H57 ��H5.3 AUTHENTICATION .................................................................................................................................... ��H58 ��H5.4 DATA INTEGRITY...................................................................................................................................... ��H58 ��H5.5 DATA CONFIDENTIALITY.......................................................................................................................... ��H58 ��H5.6 ACIS KEY MANAGEMENT........................................................................................................................ ��H58

��H6 ACIS CARD .................................................................................................................................................... ��H59 ��H6.1 APPLICATIONS IN THE ACIS CARD........................................................................................................... ��H59

��H6.1.2 ACIS Identity Card-Application.......................................................................................................... ��H61 ��H6.1.3 ACIS Privilege Card-Application ....................................................................................................... ��H61

��H6.2 ACIS PHYSICAL CARD ............................................................................................................................. ��H61 ��H6.3 ACIS AIRPORT OPERATOR ISSUED BADGE TOPOGRAPHY........................................................................ ��H62 ��H6.4 ACIS AIRCRAFT OPERATOR ISSUED BADGE TOPOGRAPHY...................................................................... ��H62

��H6.4.1 Mandatory Items on the ACIS Aircraft Operator Card ...................................................................... ��H63 ��H6.4.2 Topography Considerations for ACIS Airport Operator Local Badges ............................................. ��H63

��H7 ACIS PHASE I USE CASES.......................................................................................................................... ��H64 ��H7.1 SPONSOR APPROVAL USE CASES ............................................................................................................. ��H66

��H7.1.1 Sponsor Enrollment ............................................................................................................................ ��H66 ��H7.1.2 Agent Enrollment ................................................................................................................................ ��H68 ��H7.1.3 Agent Vetting and Adjudication .......................................................................................................... ��H70 ��H7.1.4 Optional Certificate Issuance ............................................................................................................. ��H71

��H7.2 IDENTITY CREDENTIAL ISSUANCE USE CASES ......................................................................................... ��H73 ��H7.2.1 Applicant Sponsorship ........................................................................................................................ ��H73 ��H7.2.2 Applicant Enrollment.......................................................................................................................... ��H75 ��H7.2.3 Federal Suitability Vetting.................................................................................................................. ��H76 ��H7.2.4 Extended Suitability Vetting and Adjudication ................................................................................... ��H78 ��H7.2.5 Identity Credential Issuance ............................................................................................................... ��H80 ��H7.2.6 Card Production and Personalization ................................................................................................ ��H81 ��H7.2.7 Card Activation................................................................................................................................... ��H83

��H7.3 IDENTITY CREDENTIAL MAINTENANCE USE CASES ................................................................................. ��H86 ��H7.3.1 PIN Change ........................................................................................................................................ ��H86 ��H7.3.2 Automated PIN Unblock ..................................................................................................................... ��H87 ��H7.3.3 Attended PIN Unblock ........................................................................................................................ ��H89

��H7.4 IDENTITY CREDENTIAL RE-ISSUANCE USE CASES.................................................................................... ��H91 ��H7.4.1 Lost, Stolen or Damaged Card ........................................................................................................... ��H91 ��H7.4.2 Participant Data Update .................................................................................................................... ��H93 ��H7.4.3 Employment Status Change ................................................................................................................ ��H94 ��H7.4.4 Identity Credential Re-issuance.......................................................................................................... ��H95

��H7.5 IDENTITY CREDENTIAL REVOCATION USE CASES .................................................................................... ��H98 ��H7.5.1 Suitability Status Change.................................................................................................................... ��H99 ��H7.5.2 Threat Assessment Status Change .................................................................................................... ��H100 ��H7.5.3 Identity Credential Revocation ......................................................................................................... ��H101 ��H7.5.4 Subject Revocation............................................................................................................................ ��H102 ��H7.5.5 ACIS Agent Revocation..................................................................................................................... ��H104

��H8 ACIS PHASE II USE CASES ...................................................................................................................... ��H105


February 27, 2008

Page iv

��H8.1 IDENTITY CREDENTIAL USAGE USE CASES ............................................................................................ ��H106 ��H8.1.1 Identity Verification Spot Check ....................................................................................................... ��H107 ��H8.1.2 Identity Credential PACS Registration ............................................................................................. ��H108 ��H8.1.3 Identity Credential PACS De-registration........................................................................................ ��H109 ��H8.1.4 PACS Privilege Revocation .............................................................................................................. ��H110

��H8.2 DIGITAL SIGNATURE SUBORDINATE USE CASES .................................................................................... ��H111 ��H8.2.1 ACIS Digital Signature ..................................................................................................................... ��H111 ��H8.2.2 ACIS Signature Verification ............................................................................................................. ��H112

��H8.3 IDENTITY VERIFICATION SUBORDINATE USE CASES .............................................................................. ��H114 ��H8.3.1 Level 1 Identity Verification ............................................................................................................. ��H115 ��H8.3.2 Level 2 Identity Verification ............................................................................................................. ��H116 ��H8.3.3 Level 3 Identity Verification ............................................................................................................. ��H117 ��H8.3.4 Level 3 Attended Identity Verification .............................................................................................. ��H119

��H9 ACIS PHASE III USE CASES..................................................................................................................... ��H122 ��H9.1 PRIVILEGE CREDENTIAL REGISTRATION USE CASES.............................................................................. ��H123

��H9.1.1 Privilege Credential PACS Registration........................................................................................... ��H123 ��H9.1.2 Privilege Credential Registration at Issuance .................................................................................. ��H125 ��H9.1.3 Privilege Credential Deletion ........................................................................................................... ��H127

��H9.2 PRIVILEGE CREDENTIAL USAGE............................................................................................................. ��H128 ��H9.2.1 Level 1 Card Privilege Verification.................................................................................................. ��H129 ��H9.2.2 Level 2 Card Privilege Verification.................................................................................................. ��H130 ��H9.2.3 Level 2 Biometric Privilege Verification .......................................................................................... ��H131 ��H9.2.4 Level 2 Attended Privilege Verification ............................................................................................ ��H132 ��H9.2.5 Level 3 Biometric Privilege Verification .......................................................................................... ��H134

��HAPPENDIX A - ACIS CARD DATA MODEL .............................................................................................. ��HA-1 ��HA.1 INTRODUCTION.............................................................................................................................................. ��HA-1 ��HA.2 ACIS CARD APPLICATION IDENTIFIER .......................................................................................................... ��HA-1 ��HA.3 ACIS CARD APPLICATION NAME SPACE....................................................................................................... ��HA-1 ��HA.4 ACIS DATA MODEL ELEMENTS .................................................................................................................... ��HA-2 ��HA.5 DATA OBJECT CONTAINERS .......................................................................................................................... ��HA-6 ��HA.6 DATA OBJECT REPRESENTATION................................................................................................................... ��HA-6 ��HA.7 DATA TYPES AND THEIR REPRESENTATION .................................................................................................. ��HA-7 ��HA.8 ACIS DATA MODEL ...................................................................................................................................... ��HA-7

��HAPPENDIX B - ACIS CARD APPLICATION COMMAND INTERFACE .............................................. ��HB-1 ��HB.1 SELECT CARD COMMAND.............................................................................................................................. ��HB-1 ��HB.2 OTHER CARD COMMANDS............................................................................................................................. ��HB-1

��HAPPENDIX C - ACIS PRIVILEGE APPLICATION ................................................................................... ��HC-1 ��HC.1 ACIS PRIVILEGE PACS REGISTRATION ........................................................................................................ ��HC-1 ��HC.2 ACIS PRIVILEGE PACS USE ......................................................................................................................... ��HC-2

��HAPPENDIX D - ACIS VISUAL CARD TOPOGRAPHY ............................................................................. ��HD-1 ��HD.1 MANDATORY ITEMS ON THE FRONT OF THE ACIS CARD .............................................................................. ��HD-1 ��HD.2 MANDATORY ITEMS ON THE BACK OF THE CARD.......................................................................................... ��HD-2 ��HD.3 OPTIONAL ITEMS ON THE FRONT OF THE ACIS CARD ................................................................................... ��HD-3 ��HD.4 OPTIONAL ITEMS ON THE BACK OF THE CARD .............................................................................................. ��HD-4

��HAPPENDIX E - ACIS PHYSICAL AND ELECTRICAL CARD CHARACTERISTICS......................... ��HE-1 ��HE.1 ACIS PHYSICAL CHARACTERISTICS .............................................................................................................. ��HE-1 ��HE.2 ACIS INTEGRATED CIRCUIT CARD (ICC) REQUIREMENTS ............................................................................ ��HE-1


February 27, 2008

Page v

��HAPPENDIX F - ACIS APPLICANT ENROLLMENT DATA ..................................................................... ��HF-1 ��HF.1 APPLICATION ELEMENT ................................................................................................................................. ��HF-1 ��HF.2 FULLNAMELIST ELEMENT ............................................................................................................................. ��HF-2 ��HF.3 PERSONALINFORMATION ELEMENT ............................................................................................................... ��HF-3

List of Figures ��HFigure 2-1 ACIS Identity and Privilege Concept ......................................................................... ��H12 ��HFigure 2-2 ACIS Identity-Based Access Control ......................................................................... ��H14 ��HFigure 2-3 ACIS Privilege-Based Access Control ....................................................................... ��H16 ��HFigure 3-1 ACIS Participating Entities and Authorities............................................................... ��H26 ��HFigure 3-2 ACIS System Roles .................................................................................................... ��H30 ��HFigure 3-3 ACIS System Components and Agents ...................................................................... ��H41 ��HFigure 4-1 ACIS PKI Chain of Trust ........................................................................................... ��H51 ��HFigure 4-2 ACIS Linkage of Revocable Elements ....................................................................... ��H53 ��HFigure 7-1 ACIS Phase I Use Cases Categories........................................................................... ��H64 ��HFigure 7-2 Sponsor Approval High-Level Flow .......................................................................... ��H66 ��HFigure 7-3 ACIS Identity Credential Issuance High-Level Flow................................................. ��H73 ��HFigure 7-4 Identity Credential Maintenance High Level Flow .................................................... ��H86 ��HFigure 7-5 Identity Credential Re-issuance High-Level Flow ..................................................... ��H91 ��HFigure 7-6 Identity Credential Revocation High-Level Flow ...................................................... ��H98 ��HFigure 8-1 ACIS Phase II Use Cases Categories ....................................................................... ��H105 ��HFigure 8-2 Identity Credential Usage High-Level Flow ............................................................ ��H106 ��HFigure 8-3 Digital Signature High-Level Flow .......................................................................... ��H111 ��HFigure 8-4 Identity Verification Subordinate Use Cases............................................................ ��H114 ��HFigure 9-1 ACIS Phase II Use Cases Categories ....................................................................... ��H122 ��HFigure 9-2 Privilege Credential Registration High-Level Flow................................................. ��H123 ��HFigure 9-3 Privilege Credential Usage High-Level Flow .......................................................... ��H128

List of Tables ��HTable 1-1 Glossary of Terms.......................................................................................................... ��H8 ��HTable 2-1 ACIS Phases for Airport Operators and Aircraft Operators ........................................ ��H24


February 27, 2008

Page 1

1 Introduction The Aviation Credential Interoperability Solution (ACIS) Program Office (PO), as part of the Transportation Security Administration’s (TSA) Registered Traveler (RT) and Aviation Credentialing (RTAC) Office, has developed this technical specification for a biometrics-based identification credential for the aviation industry, provisioned by federal legislative initiatives. The ACIS Credential will be issued to Airport and Aircraft Operator’s badged personnel at all federalized airports regulated by the TSA. The ACIS Program, in combination with other aviation security-related programs (e.g., Security Identification Display Area II (SIDA II)), is designed to strengthen security at the nation’s airports through the strategic application of proven secure identity authentication and related access management concepts and technologies. The TSA ACIS Program will enable a common infrastructure to exist within the aviation industry. The ACIS Program recognizes the distinctive security and regulatory environment within the aviation industry as compared to other transportation modes, in its system approach. In developing an identity credentialing program of this scale, the ACISPO has diligently worked to identify and address complex and challenging technical and operational issues that are unique to the aviation community. The ACISPO is providing this technical specification for the ACIS system which reflects technical investigation and analysis, applied credentialing system knowledge, as well as input from industry stakeholders.

1.1 Purpose The purpose of this document is to describe the ACIS System, its components and concepts of operation, along with the specifications and requirements that are needed to create an ACIS compliant system to produce and issue ACIS credentials. The ACIS Credential provides enhanced identity authentication and secure access management capabilities to ACIS cardholders and relying parties.

1.2 Scope This technical specification describes the components, operational elements and requirements which comprise an ACIS system, and which can be used by the aviation stakeholders for designing an ACIS credentialing program for issuing secure ACIS credentials. The initial aviation-related populations to be issued an ACIS credential will be badged personnel of Airport and Aircraft Operators including airport employees, flight crew and contractors. This technical specification reflects the goals and principles within the ACISPO Business Model and PO Charter. As such, this specification:

• Leverages the processes and technologies of existing TSA identity management and credentialing solutions, where appropriate;

• Is technically aligned with Federal Information Processing Standard 201 (FIPS-201) federal credentialing standards;

• Complies with industry standards, and public and private best practices; • Satisfies the identified ACIS business requirements.


February 27, 2008

Page 2

This document also describes a three-phase implementation plan for the ACIS Program, designed to achieve a rapid ACIS security benefit through the issuance and use of the ACIS identity credential, and then manage the technical and operational integration of ACIS access management capabilities in later phases.

1.3 ACIS Program Overview The ACIS Program will create a common infrastructure for issuing secure identity credentials to its aviation-related populations. The ACIS credential leverages the secure credentialing concepts of the Federal Information Processing Standard - 201 (FIPS-201), and addresses the unique aspects of the regulated aviation industry security environment. However, the ACIS Program takes a distinctive operational approach, as it contains both centralized and decentralized components within its system framework. Another unique aspect of ACIS is that it recognizes two distinct aviation populations. These two distinct populations include local and transient personnel generally ascribed here to Airport Operators and Aircraft Operators respectively. The primary ACIS Program features include the following:

ACIS Biometric Identity Credential Verification • Enhanced SIDA Challenge for local populations under responsibility of Airport

Operators using biometric cardholder verification and electronic authentication of the ACIS Card ;

• Enhanced identity verification for transient Aircraft Operator populations; • Locally selected “operational biometric” of any modality (products should be selected

from the TSA’s Qualified Products List of biometric technologies for use in airport access control systems, http://www.tsa.gov/join/business/biometric_qualification.shtm).

Common ACIS Chain of Trust • Standardized enrollment data capture; • Common “reference biometric” to support interoperable identity verification; • Common vetting process based upon existing 49 CFR Federal suitability rules; • Common credential security assurance (e.g. issuance, revocation and use); • Standardized mechanisms for accountable and auditable ACIS credential processes.

Decentralized Credentialing Framework • Standardized security assurance under ‘local span of control’ while protecting cardholder

privacy; • A common framework for integrating ID credentialing and access control systems; • Support of various access control levels (e.g., SIDA, sterile, AOA) with access privileges

assigned / granted at the local level (TSA will not play a role in determining an individual’s access privileges or level);

• Allows airports to incrementally implement systems that support their needs, while protecting investment in existing systems and processes.

Technically Interoperable and Aligned with FIPS 201-1 • Interoperable credential supporting aviation-related populations (airport employees, flight

crew, Armed LEOs, Federal Air Marshals, FAA Airman Certificate, etc.);


February 27, 2008

Page 3

• Provide technical basis for future reliance on PIV aligned identity credentials issued by external parties such as the Transportation Worker Identification Credential (TWIC), First Responder Credentials and Hazardous Materials Endorsement (HME);

• Leverage non-proprietary commercial products.

The ACIS system applies the security concepts of identity and privilege enabled by the ACIS credential in the program’s three phase implementation (Refer to Section 2).

1.4 References 1. ACISPO, Business Model (081407 v1) 2. ACISPO, PM Charter v1.0.0 09/07 3. ACISPO, Task 8 Statement of Work (8/07) 4. TWIC PMO – Various Program Guidance and System Requirement Documentation

(2006-2007) 5. RTIC Technical Interoperability Specification (2006) 6. Title 49, Code of Federal Regulations (CFR), Chapter XII, Part 1542.209 & 1544.229 7. Title 14, Code of Federal Regulations (CFR), Chapter I, Part 107 8. TSA Security Directive (SD) 1542-04-08E 9. Technical Implementation Guidance for Smart Card Enabled Physical Access Control

Systems v2.2 (http://www.tsa.gov/public/interweb/assetlibrary/TIG_SCEPACS_v2.2.pdf) 10. NISTIR 6887, Government Smart Card Interoperability Specification (GSC-IS) Version

2.1 11. ANSI INCITS 383-2008, Biometric Profile – Interoperability and Data Interchange –

Biometrics-Based Verification and Identification of Transportation Workers 12. ANSI INCITS 378-2004, Information Technology – Finger Minutiae Format for Data

Interchange 13. ANSI INCITS 358-2002, Information Technology – BioAPI Specification 14. NISTIR 6529A, Common Biometric Exchange Formats Framework (CBEFF) 15. ISO/IEC 7816, Identification cards – Integrated circuit(s) cards with contacts 16. ISO/IEC 14443, Identification cards – Contactless integrated circuit(s) cards – Proximity

cards 17. FIPS 186-2, Digital Signature Standard 18. FIPS 197, Advanced Encryption Standard 19. FIPS 46-2, Data Encryption Standard 20. FIPS 140-2, Security Requirements for Cryptographic Modules 21. FIPS-201 Personal Identity Verification for Federal Employees and Contractors

(http://csrc.nist.gov/piv-project/index.html) 22. NIST SP800-73, NIST SP800-76 23. RTCA DO 230A, Standards for Airport Security Access Control System 24. ISO/IEC 7816 Standards 25. Privacy Impact Assessment (Amended) for the Security Threat Assessment for SIDA and

Sterile Area Workers August 19, 2005

1.5 Applicable Government Regulations 1. NSPD-47 / HSPD-16 (June 20, 2006) “Aviation Transportation System Security Policy”


February 27, 2008

Page 4

2. The Homeland Security Act 2002 3. National Strategy for Homeland Security, Office of Homeland Security (OHS) 2002 4. The Enhanced Border Security and Visa Entry Reform Act 2002 5. The E-Government Act 2001 6. The Aviation and Transportation Security Act (ATSA) 2001 7. USA PATRIOT Act 2001 8. The Electronic Signatures Act 2000 9. The Government Information Security Reform Act (GISRA) 2000 10. The Government Paperwork Elimination Act (GPEA) 1998 11. OMB A-130: Management of Federal Information Resources, 1996 12. The Information Technology Management Reform Act 1996 13. The Government Paperwork Reduction Act (PRA), 1995 14. The Government Performance and Results Act (GPRA) 1993 15. The Privacy Act of 1974 16. Intelligence Reform and Terrorism Prevention Act of 2004, (December 17,2004) Title IV

– Transportation Security Section 4011 17. Title 49, Code of Federal Regulations (CFR), Chapter XII, Part 1542.209 & 1544.229 18. Title 14, Code of Federal Regulations (CFR), Chapter I, Part 107

1.6 Glossary of Terms

Access Control The automated and/or manual processes and procedures implemented to permit or deny entry to a specific facility, secured area, or computer system, including applications and databases, to ensure that unauthorized individuals are denied access and that authorized individuals are only granted access to authorized physical and logical areas.

Access Control Badge Physical credential given to a subject as a proof of a granted privilege allowing access to a physical or logical site. Depending on the access control site policy, ownership of the badge may be enough as a proof of authorization. Some other sites may in addition require a verification of the subject legitimacy (PACS PIN presentation and/or biometric verification).

Access Control Privilege Logical or physical credential issued for a subject as a proof of a granted privilege allowing access to a physical or logical site. Depending on the access control site policy, ownership of the badge may be enough as a proof of authorization. Some other sites may in addition require a verification of the subject legitimacy (PACS PIN presentation and/or biometric verification).


February 27, 2008

Page 5

Access Control System A system for electronically managing access to a specific facility, secured area, or computer system, including applications and databases, to ensure that unauthorized individuals are denied access and that authorized individuals are only granted access to authorized physical and logical areas.

ACIS Credential Physical or logical representation of an identity or privilege issued by an ACIS authority.

ACIS Employer Employer not regulated by aviation regulations (e.g. other than an airport or an aircraft operator) having employees requiring to work in an airport regulated area.

ACIS Identity Association between vetted identity claims and a subject, certified by an ACIS trusted authority.

ACIS Participant Employees of aviation regulated companies (e.g. aircraft or airport operator) or employee of an ACIS employer who have been vetted and issued an ACIS Identity Credential.

Active Credential/Card Authentication

Process involving a cryptographic processing in the card, to determine if the card is, in fact, what it is declared to be and was indeed issued by an ACIS authority.

Active Cardholder Authentication

Process using a reference information mechanism (PIN or Biometric) to determine if a cardholder is, in fact, who he/she is declared to be.

Agent Audited individual entrusted to act or represent an authority to conduct a secure task.

Air Operations Area (AOA)

Portion of an airport, specified in the airport security program, in which security measures specified in Title 49 of the Code of Federal Regulations are carried out. This area includes aircraft movement areas, aircraft parking areas, loading ramps, and safety areas, for use by aircraft regulated under 49 CFR parts 1542, 1544, and 1546, and any adjacent areas (such as general aviation areas) that are not separated by adequate security systems, measures, or procedures. This area does not include the secured area.

Airport Authority Airport operator in charge of managing and enforcing access to the AOA and secure areas according to the airport security program.

Airport Operator Operator of an airport as defined in 49 USC 47501. Airport Security Program (ASP)

Airport operator’s program required under 49 CFR 1542.101 and approved by the TSA. Airports must follow approved programs and comply and ensure those security measures outlined in the program are complied with by all tenants and users of the Airport.


February 27, 2008

Page 6

ACIS Applicant Person applying for an ACIS Identity Credential or a privilege.

Authentication Process of verifying a digital identity using challenge-response cryptographic methods.

Authorization The physical or logical access permissions (privilege) assigned to an individual.

Biographic Information containing, consisting of, or relating to the facts of a person's identity or life, i.e. place of residence or birth date.

Biometric Behavioral or physiological characteristic unique to an individual; behavioral biometrics include voice, signature, and keyboard typing technique; physiological biometrics include fingerprint, hand geometry, facial recognition, and iris recognition.

Card-application Uniquely addressable set of functionalities on an ICC that provide data storage and computational services to terminal applications.

Cardholder Person in possession of a physical credential in a form of a card (Note that this term includes both legitimate cardholders and impostors).

SIDA Challenge Demand to produce and display appropriate Airport or ACIS issued or approved ID in accordance with the ASP. Personnel with airport issued or airport approved badges are required to challenge anyone not displaying appropriate ID in the SIDA and 135AOA. Failure to display ID in accordance with the ASP will result in removal from the SIDA/135AOA. Immediate notification of airport authorities, supervisors or law enforcement officers is required to ensure the offending individual is removed from the area.

Claim Assertion by a subject about the value of an attribute of their identity.

Credential Status Status of a subject application at a given point in time (e.g. Application open, application processed, application rejected, application approved, credential issued, credential loaded in a badge, etc.).

Integrated Circuit Card (ICC)

A plastic card in which is embedded a microprocessor and memory chip storing data and programs protected by advanced security features (i.e. a smart card).

ID Card (Or ID Badge) Physical representation of an identity issued to a subject by an identity authority. A minimum of a photo of the legitimate cardholder is to be printed on the surface of the card. The same information may be encoded in an electronic component embedded in the physical card and digitally signed by the issuing identity authority.


February 27, 2008

Page 7

Identity Credential Physical or logical representation of an identity issued to a subject by an identity authority

Identity Attribute Quality or characteristic inherent in or ascribed to a subject. Identity Authority ACIS trusted entity accredited by TSA to perform the

vetting of the ACIS identity of an applicant and issue ACIS Identity Credentials. An Identity Authority may also be a sponsor of an ACIS Applicant.

Issuer Entity issuing physical credentials. Issuing Authority Entity accredited by TSA and acting on the behalf of an

Identity Authority to issue physical ACIS credentials. Local Badge Badge issued by a local authority to identify a person or

provide the person some access privileges but which is not ACIS compliant and does not have any ACIS interoperable capabilities.

Operational Biometric Biometric used by a given card issuer in the access control system under its control. Such biometrics may not be interoperable with other ACIS entities and may be added by the card issuer as an alternative to the Reference Biometric.

Passive Credential Authentication

Process consisting of verifying if the credential information is either known by the verifier (white list) or if the information is digitally signed by an entity trusted by the verifier. This process does not protect against cloning of the credential and may require an active authentication of the legitimate person presenting the credential.

Access Control Authority Trusted authority which defines the rules of the access control (airport security plan) as well as the identity attribute disclosure required from a subject to be disclosed in order to grant access privilege.

Privilege Access authorization granted by an airport authority for a person to access a specific area under the airport security plan. Sometimes called “authorization”.

Reference Biometric Interoperable biometric available in all credentials and tied to the vetting of a participant, used by all access control systems requiring interoperability between entities.

Restricted Areas Areas of the airport posted to prohibit or limit entry or access by the general public. All areas other than public areas.


February 27, 2008

Page 8

Secured Area Portion of an airport, specified in the airport security program, in which certain security measures specified in Chapter 1 of Title 49 of the Code of Federal Regulations are carried out. This area is where aircraft operators and foreign air carriers that have a security program under 49 CFR Part 1544 or part 1546 enplane and deplane passengers and sort and load baggage and any adjacent areas that are not separated by adequate security systems, measures, or procedures.

Security Identification Display Area (SIDA)

Portion of an airport, specified in the airport security program, in which security measures specified in Chapter 1 of Title 49 of the Code of Federal Regulations are carried out. This area includes the secured area and may include other areas of the airport.

Sponsor Employer vouching for a person being an employee or a contractor acting in a given capacity. The sponsor is responsible to inform the identity authority that the person has been sponsored, when the person is no longer employed or if the employment conditions (capacity/function) provided to the identity authority for the person have changed.

Sterile Area Area of an Airport which provides access to boarding to Part 121 Air Carrier Aircraft and to which access is controlled by an access control system or the screening of persons and property.

Subject A person with associated attributes. Topography The physical background “look” and the configuration of

technology and information resident on a card, including the visible security features.

Topology Topographic analysis of a card, especially the description of its features as indicated by its topography specification.

Identity Verification The act of substantiating or proving the truth of a claim of identity.

Vetting Process of inspection and adjudication of claims. Includes the verification the person is qualified according to the ACIS security requirements for individual applicants.

Visual Challenge Same as Challenge but executed by a human without the help of a reader or computer of some sort.

Table 1-1 Glossary of Terms

1.7 Acronyms and Abbreviations Automated Fingerprint Identification System (AFIS) Air Operation Area (AOA) Airport Operator Standard Security Program (AOSSP)


February 27, 2008

Page 9

Airport Security Program (ASP) American National Standards Institute (ANSI) Aviation Credential Interoperability Solution (ACIS) Card Holder Unique Identifier CHUID) Card Management System (CMS) Card Production System (CPS) Central Status Management System (CSMS) Certificate Authority (CA) Certificate Revocation Lists (CRL) Code of Federal Regulations (CFR) Common Biometric Exchange Formats Framework (CBEFF) Criminal History Records Check (CHRC) Federal Aviation Administration (FAA) Federal Information Processing Standard (FIPS) Federal PKI (FPKI) Global Unique Identifier (GUID) Identity Management System (IDMS) Immigration and Customs Enforcement (ICE) Integrated Circuit Card (ICC) International Committee for Information Technology Standards (INCITS) International Electrotechnical Commission (IEC) International Organization for Standardization (ISO) Law Enforcement Officer (LEO) National Institute of Standards and Technology (NIST) National Institute of Standards and Technology Interagency Report (NISTIR) On-line Certificate Status Protocol (OCSP) Personal Identification Number (PIN) Personal Identity Verification (PIV) Personally Identifiable Information (PII) Physical Access Control System (PACS) Privacy Impact Assessment (PIA) Public Key Infrastructure (PKI) Radio Frequency Identification (RFID) Radio Technical Commission for Aeronautics (RTCA) Registered Traveler (RT) Registered Traveler Interoperability Consortium (RTIC) Registered Traveler and Aviation Credentialing Office (RTAC)


February 27, 2008

Page 10

Security Directive (SD) Security Identification Display Areas (SIDA) Special Publication (SP) Security Threat Assessment (STA) Shared Service Provider (SSP) Office of Transportation Sector Network Management (TSNM) Office of Transportation Threat Assessment and Credentialing (TTAC) Transportation Security Administration (TSA)


February 27, 2008

Page 11

2 ACIS Concepts This section presents the basic concepts of identity on which the ACIS system is based. Although ACIS is technically aligned with PIV, it has considerations for its own program performance behaviors not addressed by PIV, as well as, an interest to maintain local control for important aspects that enhance the system and support the regulated aviation industry environment. The ACIS identity credential scheme is a relatively simple concept to grasp compared to the operational use of the ACIS credential in a local access control environment. The ACIS credential separates the notions of identity and access control enabling PACS security by use of locally managed cryptographic keys. The terminology related to identity and credentialing has rapidly evolved in the past several years. This section seeks to clarify some basic principles that are often confused and sometimes misapplied when describing credentialing programs. This section attempts to unravel the comparative differences between the notions of identity verification and access privilege, and the notion of a credential contained in a physical card or badge. These notions are at the core of key concepts for understanding the ACIS multi-phased implementation described in this specification. The three phases of ACIS implementation are introduced in this chapter and detailed in later sections.

2.1 Identity Versus Privilege The Figure 2-1 shows how the notion of identity can be differentiated from the notion of access privilege in credentialing programs. The separation of these two different notions is at the heart of the ACIS program and is one of the reasons why ACIS proposes two different types of badges as well as a multi-phased implementation. A verification of identity consists of verifying who a person is (e.g. in ACIS: the person is really who he/she claims to be and is ACIS eligible) and if the identity is still valid. It may or may not be related to an access control or an authorization of any kind. Typical access control operations follow the notion that an access privilege is granted to a person whose identity has been verified, and who has a justification for access. Figure 2.1 illustrates three distinct aspects for verification as applied to access control operations. The three aspects are represented as the three sides of a triangle, which proceeds starting from the right side and moving counterclockwise. Interestingly, there are other familiar systems like passports and visas for example, which use these notions in an analogous fashion.


February 27, 2008

Page 12

Identity

PersonPrivilege

Identity Identity VettingVetting

Local Access ControlLocal Access ControlOperationsOperations

An An IdentityIdentity

verification of a verification of a person is differentperson is different

from a privilegefrom a privilegeverification for a personverification for a personaccessing a given siteaccessing a given site

at a given timeat a given time

Privilege Privilege GrantingGranting

IdentityIdentityEnrollmentEnrollment

PACSPACSRegistrationRegistration

Figure 2-1 ACIS Identity and Privilege Concept

Looking at the right side of the figure, the first step is the verification of the person’s identity claim which is complete when the identity credential is issued to the person. Part of this step, a background check is required in ACIS in order to establish an ACIS identity credential. This is accomplished through the process of enrollment and vetting of a person’s biographic data and claim of identity substantiated by the presentation of breeder documents (e.g., driver license, social security, passport, PIV, etc.). At the end of this process, the person possesses an ACIS identity credential that binds the credential to the cardholder with biometrics collected during enrollment (and/or PIN), and to the identity authority that issues the credential with a digital certificate, therefore creating a secure chain of trust. This step is analogous to the example of a passport application and issuance. Looking at the left side of the picture, the second logical step involves the request for a local access privilege made by a person presenting an identity credential. The request may be a limited one-time access request or a frequent access request. At this stage, often called PACS registration, the access system will;

• Securely verify the person is the legitimate holder of the identity credential (e.g. credential and/or biometric authentication), and;

• Confirm that the identity credential presented is still valid (not expired or revoked by the identity issuer).

• Determine that the person has a justifiable reason to be granted access;


February 27, 2008

Page 13

After successful confirmation, an access privilege decision is made. If the process ends here, the access privilege has been granted based on identity verification (use of the Identity Credential to request access). If the justification for access involves a frequent access (e.g. due to the nature of the job assignment) a more permanent local privilege credential is then issued to the user. At the end of this second step, a local access privilege credential that supports local PACS behavior is created. A local privilege credential can be issued in various forms depending on the facility and security infrastructure. It may be issued as a simple PIN code to remember, a paper document as for a visa, or be a physical token (badge) with or without electronic features. This local access privilege credential is analogous to a visa issued by a country where a Passport is required to verify a traveler’s identity, and the visa represents a determination made by the country’s authorities to grant access for a specific purpose. Looking at the bottom of Figure 2-1, the third and final step shown in the diagram represents the operational use of the local privilege credential by the person to whom the privilege was granted. It is important to note that once the local access privilege has been issued there is no longer a need to verify the person’s identity every time (e.g. Name or address). The PACS behavior relies on the confirmation that the privilege credential is presented by the legitimate person to whom the privilege was granted and that the privilege has not been revoked. ACIS has effectively separated the two behaviors of identity verification and privilege verification in its design. These ACIS behaviors are detailed in the following sections. 2.1.1 Identity-Based Access Control

ACIS identity-based access control is closely aligned with PIV identity verification methods for access control. ACIS identity-based access control would typically be used in situations where a cardholder requires infrequent or one-time access at an attended access control point (e.g. a pilot going through a passenger security screening checkpoint). As well, in some cases, identity verification could be used for routine access (e.g. employee of an airport concession passing through a passenger security screening checkpoint) where the ACIS Identity Credential as a component of an airport issued badge could represent an implicit privilege to pass through security screening without an airline boarding pass. In an access control decision, a local PACS would verify the person’s presented claim of identity (ACIS Identity Credential, with or without biometric verification) and may need verification of justification for access (e.g. inspection of a visit authorization, manifest or badge by an attendant) proving the identity and legitimate purpose of the cardholder’s access request. In a similar manner, an Airport Security Officer could verify the ACIS cardholder’s identity using a handheld device to perform spot-checks of individuals in SIDA areas to strengthen SIDA visual challenge.


February 27, 2008

Page 14

ACIS Identity

Person

One-Time or Implicit Access

Privilege

ACIS Identity ACIS Identity VerificationVerification

IdentityIdentity--based Access based Access Control OperationsControl Operations

Access Access JustificationJustification

Verification of Verification of Access Access JustificationJustification

The process relies on trust in The process relies on trust in the ACIS identity credential the ACIS identity credential issuer along with a separate issuer along with a separate implicit (identity attribute) or implicit (identity attribute) or

explicit (visit request) explicit (visit request) justification for access. justification for access.

Access Access RequestRequest

Figure 2-2 ACIS Identity-Based Access Control

Figure 2-2 represents in the steps involved in an identity-based access control operation. It also shows an ACIS Identity does not provide automatic eligibility for access to a given site and how access control is performed using only the identity credential of the person. When an ACIS participant (a person having an ACIS Identity Credential) requires access to a given location (e.g. airport), the local access control system has, according to the local security rules, and each time, to verify the person has a valid, non revoked ACIS Identity Credential, and that the person asking for access has a legitimate justification (e.g. Aircraft CREW) for access. It is important to note that this is an Identity Credential for the ACIS system representing ACIS Federal suitability of the person but the identity may not represent all local background check requirements (e.g. financial background check) for a given Access Control Authority. When the Identity Authority issuing the ACIS Identity is the same entity as the Access Control Authority relying on the credential, the Access Control Authority has assurance that all local background check requirements have been met. For a locally issued access control badge, with embedded ACIS Identity credential, the local badge provides the verified access justification (privilege) used in conjunction with the ACIS Identity credential. In this case, the Identity Credential can be used to augment the local badge with smart card and biometric electronic identity challenge providing a high degree of assurance that the cardholder is the legitimate bearer of the local access control badge. When the Identity Authority which issued the credential is not the local Access Control Authority which manages access, specific agreement between the local Access Control Authority and the issuing Identity Authority may be required under local security policy in order to accept an ACIS Identity Credential that is not locally issued (e.g. to assure that required equivalent non-Federal background checks have been performed). Additionally, a separate justification


February 27, 2008

Page 15

(authorization) is generally required in conjunction with the Identity Credential (e.g. visit request/authorization or manifest), based upon local security policy. It is important to note that while possession of an ACIS Identity Credential does not explicitly grant any access privilege, it is possible to use the ACIS Identity Credential to represent an implicit privilege, based upon local security policy, in order to grant certain types of access. This is analogous to the use of a passport as an implicit privilege to enter the issuing country without an explicit visa. For example, when the issuing Identity Authority is the same entity as the Access Control Authority, the locally issued ACIS Identity Credential could be used for general types of access control (e.g. employee of an Airport concession could use the ACIS Identity Credential to pass through a passenger screening checkpoint without an airline boarding pass). Similarly, assuming agreement by the local access Control Authority to accept an ACIS Credential from a different Identity Authority (e.g. Aircraft Operator), the ACIS Credential issued by that Identity Authority could be used to represent implicit privilege for individuals carrying Identity Credentials issued by that Identity Authority (e.g. a flight crew of a specific air carrier could use the Identity Credential to pass through a screening checkpoint or to access a gate of that Air Carrier. 2.1.2 Privilege-Based Access Control

Figure 2-3 represents the steps in a privilege-based access control operation. When a person requires frequent access to a given location, it is cumbersome to verify the purpose for access and the validity of the identity credential each time. Local access control systems (PACS) manage privileges for a given person by allowing the identity link (identity credential information) to be registered in the PACS, storing once the justification and the details for this specific access privilege (e.g. cleaning personal allowed at given time of day). The person is then provided a local access control privilege which allows the PACS to know that the identity and justification verification has been performed, is still active and access can be granted to the legitimate bearer. The verification at an access point that the user is the person to whom the privilege was granted can be achieved using a PIN and/or a biometric verification. The PACS performs periodic verification of potential identity revocation. It is important to note that at this point, the identity does not need to be verified for each access control operation since it has been previously verified at PACS registration and is maintained up to date by the PACS in the background.


February 27, 2008

Page 16

ACIS Identity

PersonRegistered

Access Privilege

ACISACISIdentity Identity VerificationVerification

PrivilegePrivilege--based Accessbased AccessControlControl

OperationsOperations

Access Access Privilege Privilege Eligibility Eligibility DeterminationDetermination

Site Site Access Access RequestRequest

Local PACSLocal PACSRegistrationRegistration

After an ACIS identity verification is After an ACIS identity verification is performed, the eligibility for SIDA performed, the eligibility for SIDA

access is determined and a local access access is determined and a local access privilege credential (ACIS Privilege) is privilege credential (ACIS Privilege) is

delivered for frequent access to the sitedelivered for frequent access to the site

Figure 2-3 ACIS Privilege-Based Access Control

In many access control systems where the identity issuer is the same entity as the access control manager, the badge issued is called an identity badge and is used at the same time for access control. ACIS separates these two notions while providing an incremental approach to achieve standardized smart card and biometric-based privilege verification for access control in the final ACIS phase. In the first two phases of ACIS an ACIS Identity Credential is embedded in the local identity/access control badge. In these two phases, local identity/access control badges operate in the same manner as they do today, using the existing access control technologies of the local identity/access control badge. The embedded ACIS Identity credential is used to support registration of a Participant in the local PACS, but is not used directly for physical access control operations. This PACS registration provides a strong mechanism to manage revocation of local identity/access control badges based upon the revocation of the ACIS Identity Credential. By periodically checking status of the ACIS Identity Credential, the PACS can determine if the credential has been revoked and propagate revocation of the local identity/access control badge. As well, ACIS provides mechanisms to assure that Identity Credential Revocation is propagated across all ACIS Identity Authorities and Access Control Authorities as required. In the third phase of ACIS, a separate smart card application (ACIS Privilege Application) provides specific support within the ACIS smart card chip for standardized smart card and biometric-based privilege verification for access control. At the time of PACS registration, the Identity Credential is verified and the cardholder is biometrically verified, in order to transfer trust from the ACIS Identity Credential (Identity Authority) to the local PACS (Access Control Authority). Once trust is transferred to the local PACS, the PACS uses the ACIS Privilege Application with locally managed keys to provide efficient and secure card and biometric


February 27, 2008

Page 17

verification in access control, with stronger security and privacy protections (particularly using contactless smart card interfaces) than afforded using PIV methods. Use of the ACIS privilege application eliminates the need to perform time consuming and complex identity verification using PKI at each access point. As in the first two phases of ACIS

2.2 Local Employees Versus Transient Employees In the ACIS program, two different types of badges (physical cards) are defined. All ACIS badges will contain an ICC chip; however the printed topography will vary in two important ways. ACIS Airport Operator badges issued for local employees working at a given airport are under the control of the local Access Control Authority and will have a topography satisfying the SIDA regulation (CFR 49 part 1542 section 211). These badges are also used for local access control operation. The second type, ACIS Aircraft Operator badges are issued to personnel (e.g., crew) requiring access to multiple airport locations. With no common topography between airports being available, such badges cannot include markings suitable to support the SIDA Challenge program. Their specific topography is defined in this specification (ACIS topography for Aircraft Operator badges). In the following sections, these two types of badges are called either ACIS Aircraft Operator credentials or ACIS Airport Operator credentials. The ACIS Aircraft Operator badge is not used for local access control in ACIS Phase I and II.

2.3 Centralized Versus Distributed System Concepts The ACIS program credentialing architecture is decentralized, much like PIV. The credential issuing authorities (ACIS Identity Authorities) are independent but operate under the rules of the ACIS program. In ACIS, the Airport and Aircraft Operators, issue the credentials and manage the credentialing systems including the responsibility for all ACIS Identity Authority processes. These ACIS issuers compare to the federal agency issuers in PIV. Similarly, the ACIS access control system architecture is inherently distributed, with access control management under local control of ACIS Access Control Authorities. The ACIS decentralized architecture supports the need to allow local authority and autonomy necessary for managing the operations of the federally regulated aviation industry. In contrast to PIV, the ACIS program uses centralized system components that provide services to ACIS Identity Authorities. These services are either inherently centralized in nature (e.g. to support Federal identity vetting and ACIS-wide biometric duplicate checks) or centralized to provide a standardized and economical means to establish a chain of trust between distributed ACIS Identity Authorities and those entities (Identity Authorities and Access Control Authorities) relying on the ACIS Credential (relying parties). The ACIS program has two centrally managed components:

• The ACIS Central Status Management System (Federal vetting services, biometric duplicate check and communication of revocations between ACIS Identity Authorities);

• The ACIS Root Certificate Authority (ACIS root CA acting as the trust anchor for ACIS Identity Authority subordinate CAs.


February 27, 2008

Page 18

The other components required to execute the various tasks required by ACIS credential management are decentralized and may be implemented as outsourced shared services, in a model similar to the PIV Shared Service Provider (SSP) model supporting multiple issuers in order to optimize costs. These components are:

• Enrollment, physically decentralized but can be implemented as a shared service between ACIS Identity Authorities;

• Identity Management, under the control of the Identity Authority and even if a shared service provider is used, each Identity Authority will a logically separate IDMS.

• Identity Vetting and Adjudication, under the control of the Identity Authority even though it relies on centralized Federal vetting services.

• Identity Authority CA, distributed Certificate Authorities and Validation Authorities which are implemented using Federal PKI (FPKI) Compliant shared service providers;

• Credential Issuance and Management, closely linked with the IDMS and is decentralized and logically separated between Identity Authorities, even though it can be physically centralized at a location using a shared service provider.

• Card Production, distributed among Identity Authorities is either centralized (for each Identity Authority) with a centralized manufacturing process (card suppliers) which may print, personalize and deliver the cards (physical credentials), or hybrid using a local personalization printer producing badges locally using a pre-printed, pre-personalized stock of centrally manufactured cards.

Two services, dealing directly with the airport security are by nature completely decentralized: • Privilege Granting is under the responsibility of each airport which decides the rules of

access on its grounds and proposes a security plan to TSA for approval. • Access Control is the responsibility of the security manager of the airport who controls

all the elements related to the PACS used at the facility.

2.4 Leveraging PIV and Existing TSA Credentialing Programs For use as an identity credential, PIV specifications can be applied almost directly in ACIS for issuance of an ACIS Identity Credential, with relatively small adaptations to the PIV model. These adaptations to the PIV identity credential model are primarily required to address differences between ACIS issuing entities, employee populations, vetting sources and regulatory authorities as compared to Federal Government Agency PIV issuers. A primary distinction between ACIS and PIV exists due to the specific ACIS goal of establishing a framework for biometric verification within airport access control systems. Use of biometrics for airport physical access control employing contactless physical access control technologies is not currently addressed within PIV specifications. The ACIS system defines extensions to the PIV credential model to support an ACIS Privilege Credential capable of meeting security, privacy and operational needs of Airport Operators. The ACIS Privilege Credential scheme as described in this specification is focused on maintaining local span of control of Airport Operators over airport physical access security while providing standardized security assurance and appropriate cardholder privacy. The TWIC is a PIV-aligned credential system that addresses credentialing of private sector employees of multiple private sector employers, as opposed to credentialing of employees (and


February 27, 2008

Page 19

contractors) of a single Government Agency as in PIV. For this reason, enrollment data models used in TWIC provide PIV-aligned specifications that are more closely aligned with credentialing of ACIS cardholder populations than in PIV. Use of TWIC enrollment data models as a basis for ACIS establishes ACIS systems that are aligned with data capture and retention policies that are appropriate for Non-Federal employees. From a perspective of establishing a chain of trust between distributed ACIS credential issuers and distributed ACIS relying parties (organizations using the credential for identification or access control decisions), ACIS leverages concepts developed under the RT Program’s Central Information Management System. Concepts developed under the RT program are applied in ACIS to enhance trust in ACIS identity vetting through use of ACIS-wide automated fingerprint identification of ACIS applicants and to convey credential revocation information between ACIS issuers. This provides an important mechanism within ACIS to detect individuals applying for ACIS credentials who have been previously rejected as unsuitable by other ACIS issuers who may attempt to reapply in other locations under a fraudulent identity. Additionally, this approach provides a mechanism to cascade revocation of multiple ACIS credentials issued to an individual by multiple ACIS issuers in cases where a security threat associated with that individual has been identified or a disqualifying condition has been identified by a single ACIS issuer.

2.5 ACIS Phased Implementation ACIS deployment capability and schedule is enhanced by its alignment to the PIV identity credentialing model. In many areas of ACIS, this alignment allows ACIS stakeholders to leverage existing PIV specifications, products and services as a basis for ACIS implementation. In other areas, such as PACS integration and privilege based access control, the full ACIS implementation requires changes to existing Airport PACS infrastructure, and operational protocols, and is phased over time taking into account the complexity, costs and impacts of such changes. The following ACIS phases are defined within this specification:

• Phase I - ACIS Identity Credential for all aviation personnel; • Phase II - ACIS Electronic Identity Verification for all aviation personnel; • Phase III - ACIS local access Privilege Credential for transient personnel.

2.5.1 ACIS Phase I – ACIS Identity Credential

The first phase of the ACIS program focuses on the issuance and use of a secure identity credential by Airport Operators and Aircraft Operators that is aligned with the PIV identity credentialing model. The proposed ACIS Phase I implementation assumes that PIV is well understood and supported today within the credentialing industry. Hence, the ACIS Identity Credential Phase can be implemented and deployed relatively quickly, leveraging the availability of existing FIPS-201 approved products and services. The primary goal of Phase I of ACIS is to establish a common basis for the ACIS identity among all aviation entities (same background checks and same identity management rules). The ACIS Identity Credentials issued at the end of phase I will guarantee the user is eligible for ACIS and is who he/she claims to be. Beginning in ACIS Phase I, all ACIS badges will be issued with an electronic ACIS Identity Credential available in the form of a contact ICC chip on all badges, allowing the next phases to rely on an interoperable, verifiable ACIS Identity Credential.


February 27, 2008

Page 20

In all cases, an ACIS identity credential will employ a contact ICC chip that is technically aligned with the PIV electronic identity model, in the badges issued by Aircraft Operators to their transient personnel as well as an ACIS access control badge issued by Airport Operators to their local populations. For the ACIS identity badge issued for transient populations the topography is defined in Appendix D – ACIS Visual Card Topography. For an ACIS access control badge issued by airport operators, the existing topography of each airport badge needs be adjusted to accommodate the addition of the contact ICC, but otherwise respects the existing Airport SIDA Badge topography and Airport PACS access card technologies (e.g. magnetic strip, proximity chip or bar code), and does not specifically require the presence of the contactless ICC interface defined by PIV.

2.5.1.1 ACIS Aircraft Operator Identity Credential ACIS Aircraft Operator identity credentials, issued mainly to transient population, do not have specific features to allow them to be used by a local access control system of an airport during ACIS Phase I. Aircraft operators may chose to include the contactless PIV interface on their badges, but the ACIS specification does not rely on the presence of this feature during any phase of the program. The ACIS Program recognizes that some airport operators have more stringent suitability criteria than ACIS (e.g. additional restrictions on CHRC results) and may need to do additional background checks (extended vetting) before accepting an ACIS Identity credential issued by a different Identity Authority as an interoperable identity credential (breeder document) by transient personnel.

2.5.1.2 ACIS Airport Operator Identity Credential ACIS Airport Operator identity credentials, issued to the local population of a given airport, may have airport specific features allowing them to be used by the airport local access control system. The ACIS Airport Operator identity credential may be issued under more stringent suitability criteria than ACIS Federal suitability rules (e.g. additional restrictions on CHRC results or extended vetting criteria) but do meet all basic ACIS Federal suitability requirements and as such can be used as an interoperable identity credential in any phase of ACIS representing ACIS Federal suitability. The addition of the ACIS Identity Credential secure ICC provides strong identity assurance to airports and an interoperable ACIS Federal suitability assurance allowing ACIS electronic identity challenges by airports through the use of devices such as handheld biometric verification readers based upon available PIV compliant products.

2.5.1.3 Standardized ACIS Assurance Levels and Chain of Trust Phase I of ACIS establishes standardized levels of assurance and a complete chain of trust in identity vetting and identity authentication based upon FIPS-201 aligned credentialing mechanism and secure processes. ACIS processes and mechanisms to establish standardized levels of assurance and chain of trust include:

• Standardization of ACIS enrollment data capture;


February 27, 2008

Page 21

• Centralized biometric identification of ACIS applicants using an Automated Fingerprint Identification System (AFIS) to assure that previously rejected applicants or repudiated ACIS participants cannot reapply for ACIS using a different identity;

• Use of standardized ACIS Public Key Infrastructure (PKI) to certify ACIS identities issued by ACIS issuers;

• Use of ACIS trusted agent roles for individuals performing key operational tasks within the ACIS system in order to establish individual accountability and technical non-repudiation for critical tasks such as review of breeder documents, approval of ACIS credential issuance or ACIS credential revocation.

• Use of standardized levels of security mechanisms and auditing with ACIS system elements;

• Accreditation of ACIS Entities responsible for ACIS system operation; • Use of ACIS approved credentialing system products and services.

This standardized level of assurance and chain of trust will provide a basis for ACIS stakeholders, as relying parties (Airport Operators), to trust and accept ACIS credentials issued by other ACIS issuing authorities (e.g. Aircraft Operators or other Airport Operators).

2.5.1.4 Automated Revocation of Multiple ACIS Credentials Issued to an Individual When the ACIS suitability status of a person changes (modification of STA or CHRC status) and this information becomes known to the ACIS program, the ACIS Central Status Provider will communicate to identity authorities the information, allowing them, in turn to revoke any identity credential they would have issued to an individual. 2.5.2 ACIS Phase II – ACIS Electronic Identity Verification

In ACIS Phase II, the ACIS identity credential (the contact ACIS ICC available on all ACIS badges) is available to all aviation employees allowing identity verification of ACIS cardholders. The ACIS credential during this phase might be an ACIS aircraft operator badge, or an ACIS airport operator badge (ACIS ICC only incorporated into an airport local access control issued badge). Either way, during this phase, the ACIS credential can be used for identity based verification of ACIS cardholders. This includes using the ACIS credential in handheld reader devices to verify that the cardholder is legitimate (biometric verification of identity) as well as for granting of Airport access privileges and registration into Airport PACS. ACIS PACS registration and privilege granting will be supported through automated PACS enrollment processes for existing ACIS participants. Using ACIS Identity Credentials during PACS registration as a breeder document allows the PACS to revoke access privileges registered under the identity credential upon revocation of the identity credential. During Phase II, the aviation industry will be able to deploy and adapt to the ACIS new identity credential. During this period, TSA along with the aviation industry will also be able to overlap with some required developments for phase III providing the detailed specification of the ACIS privilege application resulting in products available sooner for deployment in phase III.


February 27, 2008

Page 22

2.5.2.1 Use of PIV-Based Handheld Terminals to Strengthen the SIDA Challenge The ACIS identity credential being aligned with PIV allows the use of PIV compliant terminals with very minor modifications. Many of such terminals are being made available by the industry and support verification that:

• The credential is authentic (PIV card authentication challenge); • The credential has not been revoked (Online Certificate Status Protocol (OCSP) or

Certificate Revocation List (CRL) check); • The cardholder is the legitimate cardholder (PIN presentation and biometric verification).

During Phase II, deployment of such terminals will strengthen the SIDA challenge and allow progressive migration to an electronic challenge, providing biometric verification of the cardholder as well as a strong assurance of the badge authenticity. ACIS electronic card authentication provides strong authentication and validation of the ACIS credential through cryptographic challenge protocols protecting against cloned or fraudulent badges. ACIS biometric verification provides strong assurance though fingerprint matching of the ACIS cardholder to the ACIS card that the cardholder who presents the ACIS card is the legitimate cardholder to whom the credential was issued.

2.5.2.2 Use of ACIS as an Identity Authentication Document for PACS Registration The ACIS identity credential can be used as a secure breeder document for registration of ACIS Participants into Airport PACS. As a breeder document, ACIS will allow Airports to electronically verify an individual’s identity and biometrically authenticate the cardholder with the presented ACIS credential prior to registration and granting of access privileges to an individual. This can reduce an Airport’s costs associated with access badge processing by providing the ability to confidently use the ACIS credential to confirm an individual’s security suitability in terms of represented STA and CHRC vetting. The use of an ACIS identity credential will also provide Airports the ability to validate that the ACIS credential has not been revoked, based upon centralized ACIS mechanisms including an ACIS Public Key Infrastructure.

2.5.2.3 Automated Revocation of PACS Privileges Upon revocation of an ACIS identity credential, the credential identifier will be incorporated in the ACIS CRL and each airport that has granted privileges to that ACIS credential will be required to revoke local access privileges granted based upon this identity credential. This process approach for ACIS revocation will help to ensure that any access privileges granted by an airport will be revoked upon determination that an ACIS cardholder either no longer has a need for the granted privilege (e.g. based upon termination of employment) or has been determined to be unsuitable for access to an Airport. 2.5.3 ACIS Phase III - ACIS Privilege Credential

In ACIS Phase III, the ACIS Privilege Credential additionally supports the use of card authentication and biometric verification in Physical Access Control Systems. This capability is achieved over the contactless interface with locally managed keys. This support will be enabled through additional features of a new electronic application residing on the ACIS card. This ACIS Privilege Card-Application available in Phase III will support secure registration of local


February 27, 2008

Page 23

access privileges to the ACIS credential using local Airport security identifiers and key management. This later implementation phase proposes additional functions to a PIV-aligned credential for biometric-based physical access control allowing protection of personally identifiable information (PII) exchanged between the card and the reader over the contactless interface and providing fast execution time with high security. The contactless access control features provided by the existing implementation of PIV disclose personally identifiable information from the card (CHUID) requiring the card to be kept in an electromagnetically opaque sleeve when not in use. The PIV contactless access control features also rely on public key cryptography which impacts performance and do not support biometrics over the contactless interface. The ACIS Phase III credential provides a solution using locally managed symmetric key cryptography which completely protects user’s personally identifiable information (including biometric) without having to use a PIN, providing high security and fast response time. Industry and stakeholder involvement is needed to define final specifications for ACIS use in PACS.

2.5.3.1 Implementation of ACIS PACS Privilege Credential Specification The ACIS privilege application deployment will be preceded by a technical specification development effort. The first part of this effort, which may start in parallel with Phase I or Phase II of the program, would involve ACIS PACS Authorities and the PACS industry developing and agreeing on the specification of the ACIS privilege card application features. The second part of this effort will be to update existing credentials or issue new ACIS credentials containing the ACIS Privilege Card-Application and modify/adapt legacy PACS and terminals to take advantage of the updated features of the new ACIS credentials. 2.5.4 Summary of ACIS Phases and Credential Deployment

The table below summarizes the main assumptions on which this document is based and the two types of badges proposed during the three phases. Phase 1 establishes the ACIS Identity Credential issuance infrastructure, establishes chain of trust in the ACIS Identity credential and begins ACIS Identity Credential issuance. An ACIS ICC chip is embedded in an Aircraft Operator Card using standard ACIS badge topography. An ACIS ICC chip is embedded in the existing Airport Operator local badge with existing Airport SIDA topography and supporting backward compatibility with existing Airport PACS technologies. In Phase II, the ACIS Identity Credential is used for identity-based verification using PIV-aligned contact smart card and biometric verification functions enabled through PIN entry. Phase II supports PACS registration and identity-based access control with implicit privilege (such as to support employee biometric verification when moving from the public area to the secure area). Phase II includes electronic identity challenge to enhance SIDA challenge and PACS registration to support revocation of PACS privileges upon revocation of the ACIS Identity Credential. In Phase III, the ACIS Privilege Credential is deployed, either through update to existing ACIS Phase I cards or re-issuance of ACIS Phase I cards. Airport PACS are incrementally upgraded to accept the ACIS Privilege Credential. Backward compatibility of legacy PACS card


February 27, 2008

Page 24

technologies may be maintained by ACIS Access Control Authorities in order to ease transition to the ACIS Privilege Credential.

Phase I Phase II Phase III

ACIS ID Credential ACIS Badge Topography

Physical Access Control

ACIS ID Credential Use

ACIS Biometric Physical Access Control

Airport Operator issued badge (local population)

Existing SIDA Topography and Visual Challenge

Local proprietary PACS solution - No change to existing PACS.

Biometric Identity Verification - SIDA Challenge (handheld devices) - PACS Registration

ACIS Biometric Access Control PACS Privilege Verification - ACIS privilege credential (reference biometric) or approved legacy PACS credential (e.g. operational biometric)

Aircraft Operator issued badge (transient population)

PIV-aligned contact chip embedded in Aircraft Operator badge or existing Airport Operator local badge - Biometric ID Verification - Identity Chain of Trust - Identity Credential Revocation

Standardized ACIS ID Card Topography based upon

PIV.

- Not used for access control

Biometric identity Verification - Challenge of non-SIDA Transient population (e.g. flight crews)

ACIS Biometric Access Control PACS privilege verification - ACIS privilege credential available (reference biometric) for access control at multiple airports

Table 2-1 ACIS Phases for Airport Operators and Aircraft Operators


February 27, 2008

Page 25

3 ACIS System Overview At its fundamental level, the ACIS system is comprised of coordinated entities, roles and system elements operating within a PIV-aligned credentialing scheme. By leveraging PIV specifications as a basis for the ACIS scheme, the ACIS program takes advantage of existing PIV concepts, requirements, products and services as a means to efficiently deploy an interoperable aviation credential solution. Due to differences in size, structure, regulation, authorities and operational needs of entities participating in ACIS, as compared to Federal Government Agencies, adaptations are required to apply a PIV-aligned solution within the aviation community. In addition to leveraging PIV specifications, the ACIS system leverages concepts and requirements from existing TSA credentialing programs, including the Transportation Worker Identification Credential (TWIC) and Registered Traveler (RT) programs. In order to aid in understanding of the ACIS system, a brief description of how ACIS leverages PIV and other existing specifications is provided in section ��H2.4, ��HLeveraging PIV and Existing TSA Credentialing Programs. Much of the security assurance and chain of trust within the PIV and ACIS credential schemes rely on a formalized and standardized model of participating entities, responsibilities, system roles and system elements. This standardization within the PIV and ACIS system models provides a uniform basis for certification and accreditation of participating entities and approval of standardized products and services. This uniform basis in accreditation and approval is essential to allow ACIS entities to trust credentials issued by other ACIS entities. This uniform basis in accreditation and approval is also essential in order to allow a single ACIS entity to implement security systems using technology products that function at know security and assurance levels, appropriate for threats, risks and potential impacts in each security system application. The subsequent sections of this chapter outline the ACIS system in terms of ACIS entities, system roles and system components.


February 27, 2008

Page 26

3.1 ACIS Participating Entities ACIS participating entities comprise a partnership of Aviation Sector and Federal entities who participate in the ACIS program. ACIS participating entities are those individuals and organizations who are either responsible for various aspects of aviation security programs for federally regulated airports or federally regulated air carriers or who have a justified need through employment relationships to be granted access privileges at federally regulated airports.

ACIS Identity Authorities

Aircraft OperatorAirport

Operator

TSA

Federal Government Vetting Services

Exclusive Area

OperatorAirport TenantAirport

Operator

ACIS Access Control Authorities

ACIS Program and Compliance Authority

Local Vetting

Providers

TWIC Identity

AuthorityNon-ACIS Identity Authorities

First Responder

Identity AuthorityGovernment

Agency Identity

Authority

ACIS Employers and Employees

Aircraft Operator

ContractorAirport

Operator Contractor

Airport and Aircraft

Operator

ACIS Identity

Local Access PrivilegeLocal Access Local Access

Control OperationsControl Operations

Local PACS Local PACS RegistrationRegistration

Eligibility Eligibility DeterminationDetermination

Federal Federal Identity Identity VettingVetting

Identity Identity CredentialCredentialIssuanceIssuance

ACIS ACIS ComplianceCompliance

Identity

Local Local Identity Identity VettingVetting

IdentityIdentityEnrollmentEnrollment

Aviation Aviation Security Security RegulationRegulation

Person

Site Site Access Access RequestRequest

Access Privilege Access Privilege Eligibility Eligibility DeterminationDetermination

ACISACISIdentity Identity VerificationVerification

ACIS Status ACIS Status ManagementManagement

ACIS PKIACIS PKI

ExtendedVetting Services

TSA RTACTSA

TSNM

FBI

Federal Entities

Non-Federal Entities

Figure 3-1 ACIS Participating Entities and Authorities

3.1.1 ACIS Aviation Sector Entities

ACIS Aviation Sector entities are state and local government entities, commercial entities and individuals conducting aviation related businesses at federally regulated airports. ACIS Aviation Sector entities include:

• Aviation Employees; • Aviation Employers; • Airport Operators; • Airport Tenants;


February 27, 2008

Page 27

• Airport Exclusive Area Operators; • Aircraft Operators, and; • Extended Vetting Service Providers.

3.1.1.1 Aviation Employees Aviation employees are those individuals who require access to federally regulated airport facilities in the performance of their aviation-related employment. The scope of the initial ACIS specifications covers the largest categories of aviation employees who are employed by aviation employers described in the next section. Other categories of aviation employees (e.g. Federal Air Marshals, Law Enforcement Officers, First Responders), are not covered in this specification and will be addressed in future ACIS phases.

3.1.1.2 Aviation Employers In the ACIS system, an Aviation Employer is an entity (e.g. company, contractor or owner) that provides employment to ACIS Aviation Employees. ACIS aviation employers include:

• Airport Operators; • Aircraft Operators; • Airport Operator Contractors, and; • Aircraft Operator Contractors.

The ACIS Aviation Employer is responsible for providing justification of an Aviation Employee’s need for airport access privileges, based upon the Aviation Employee’s job function.

3.1.1.3 Airport Operators Airport Operators are operators of federally regulated airports who are regulated by TSA under 49 CFR Section 1542.209 (Airport Operators).

3.1.1.4 Airport Tenants Airport Tenants are non-Aircraft Operator airport businesses responsible for managing access to Airport Tenant facilities under a Tenant Security Plan, subordinate to Airport Operators.

3.1.1.5 Exclusive Area Operators Exclusive Area operators are Aircraft Operators operating under and Exclusive Area Agreement who have assumed responsibility under 49 CFR Section 1542 for managing access to Aircraft Operator Exclusive Areas subordinate to Airport Operators.

3.1.1.6 Aircraft Operators Aircraft Operators are operators of aircraft who are regulated by TSA under 49 CFR Section 1544 (Aircraft Operators).

3.1.1.7 Extended Vetting Service Providers Extended Vetting Service Providers are State, Local and Commercial entities acting as identity vetting and background investigation information providers for Airport Operators and Aircraft Operators. Extended Vetting Service Providers provide additional Aviation Employee vetting beyond that information required to determine suitability for airport access under 49 CFR 1542


February 27, 2008

Page 28

and 49 CFR 1544 federal rules. Extended vetting can be viewed as vetting that “extends” Federal rules based upon Airport Operator or Aircraft Operator local suitability rules or as is required to satisfy state or local regulations. As entities responsible for providing vetting information for overall Aviation Employee suitability determination by Airport Operators and Aircraft Operators, it is important to recognize Extended Vetting Service Providers as entities who interact with the overall ACIS scheme. However, since vetting provided by Extended Vetting Service Providers is in addition to that required under Federal Regulations, specific requirements associated with Extended Vetting Service Providers are outside the scope of this specification. 3.1.2 ACIS Federal Entities

ACIS Federal entities are Government entities responsible for regulating and supporting aviation security operations at federally regulated airports. ACIS Federal entities include:

• Transportation Security Administration, and; • Federal Government Vetting Service Providers.

3.1.2.1 Transportation Security Administration The TSA is the exercising authority for rules governing airport security under 49 CFR Part 1542, Airport Security and 49 CFR Part 1544, Aircraft Operator Security: Air Carriers and Commercial Operators. TSA has established the ACIS Program Office (ACISPO) under the TSA Registered Traveler and Aviation Credentialing (RTAC) Office, responsible for development of this specification. The TSA's Office of Transportation Sector Network Management (TSNM) leads the unified national effort to protect and secure our nation's transportation systems. TSNM develops new policy and reviews existing policy for needed modification or elimination based on the evolving threat to commercial aviation. TSNM Commercial Airports Division is the primary policy and program entity for all commercial airports.

3.1.2.2 Federal Government Vetting Service Providers Federal Government entities participate in ACIS as Federal Government vetting service providers for Airport Operators and Aircraft operators. Federal Government vetting service providers include:

• Office of Transportation Threat Assessment and Credentialing (TTAC) responsible for performing TSA Security Threat Assessment (STA) and facilitating fingerprint-based Criminal History Records Checks (CHRC), submissions to the FBI and providing FBI responses to facilitate air carrier and airport employer Adjudication of the results, and;

• The FBI, responsible for performing the fingerprint-based CHRC on ACIS applicants. 3.1.3 Non-ACIS Credential Issuers

Non ACIS credential issuers are Federal, State and Local Government entities or associated Non-Federal entities with employees requiring access to Federally Regulated Airports such as employees of regulatory agencies, law enforcement agencies and first responder organization. Non-ACIS Credential Issuers in these categories are generally issuers (or plan to be issuers) of


February 27, 2008

Page 29

FIPS 201 PIV (Personal Identity Verification) Federal Agency credentials or non-Federal Agency issued PIV-aligned identity credentials. Because ACIS identity credentials are based primarily upon Federal PIV standards and associated PIV specifications, the ACIS system provides a basis for future technical interoperability with PIV or PIV-aligned credentials issued by Non-ACIS Credential Issuers. However, it is important to note that the ACIS credential is not directly interoperable with PIV or other PIV-aligned credentials. Full interoperability with PIV would imply that an ACIS credential could be directly accepted by a Federal Government Agency and that a Government Agency PIV credential or PIV-aligned credential could be accepted directly in an ACIS compliant system. This level of interoperability cannot be achieved simply through technical means and would require significant policy development in order to be realized in a standardized aviation industry-wide manner. While the ACIS identity credential is not directly interoperable with PIV, use of a PIV aligned ACIS identity credential does anticipate future standardized reliance of Airport Operators on Government Issued PIV credentials. Alignment of ACIS with PIV establishes a technical framework within Federally Regulated Airport systems that can be enhanced to accept Federal Government Agency issued PIV Identity Credentials or other PIV aligned identity credentials such as those associated with First Responder credential initiatives. Such future acceptance of non-ACIS PIV or PIV-aligned credentials by Federally Regulated Airports is outside the scope of this specification.


February 27, 2008

Page 30

3.2 ACIS System Roles This section describes the ACIS system roles that are performed by an ACIS Entity. All the ACIS Entities have assigned roles which provide the fundamental activities that establish an ACIS identity, coordinate and manage ACIS system data, and ensure and enable a reliable chain of trust represented by the issued ACIS identity credential through its life cycle. All ACIS roles and processes will be managed by accredited ACIS Authorities. ��HFigure 3-2 ACIS System Roles shows the relationship of the ACIS Roles to the ACIS Entities and Authorities.

TSA ACIS Program

Credential Status Validation

ACIS Applicant Sponsorship and Enrollment

Local Access Privilege Use

ACIS ID Credential Issuance

Criminal History and Threat AssessmentStatus

Extended Vetting Services


FBICHRC TSA

STA

Airport Operators(ACIS Access Control

Authorities)TSA

ACIS Program

Aircraft and Airport Operators (ACIS Identity Authorities)

Aviation Employers

ACIS Compliance Authority

ACIS Central Status Provider

ACIS Identity Credential

Issuer

Airport PACS

Operator

ACIS Specifications

ACIS Product/Service Approval

ACIS Accreditation

ACIS SponsorACIS Applicant

ACIS Privilege

Issuer

Local PACS Access Privilege Granted

Identity StatusNotification

ACISParticipant

(“Cardholder”)

Identity Credential

ID Verification for Privilege Granting

Access Control Credential

ACIS Identity Adjudicator

ACIS Identity Vetting and Certificate Requests

Non-Federal Required Vetting

ACIS Certificate Authority Provider

ACIS Enrollment

Manager

Federal Entities


ACIS System Roles

Figure 3-2 ACIS System Roles

3.3 ACIS Aviation Sector Roles ACIS Aviation Sector roles include both individual roles, and system roles. System roles are roles assigned to ACIS entities and authorities associated with functions of ACIS systems. Individual roles are those roles assigned to a single person. ACIS Aviation Sector Roles include the following:


February 27, 2008

Page 31

• ACIS Sponsor; • ACIS Applicant; • ACIS Participant; • ACIS Agent; • ACIS Adjudicator - Identity Authority role • ACIS Enrollment Manager - Identity Authority role • ACIS Identity Credential Issuer – Identity Authority role • ACIS Privilege Issuer – Access Control Authority role • ACIS PACS Operator – Access Control Authority role

3.3.1 ACIS Sponsor

The ACIS Sponsor is an aviation employer who sponsors its employees in their application for an ACIS credential. The ACIS Sponsor designates an individual to act on the behalf of the sponsor as the ACIS Sponsor’s Agent. Designation of a Sponsor’s Agent provides individual accountability as well as Sponsor organizational accountability for all requests made to the ACIS Identity Authority by the ACIS Sponsor. The ACIS Sponsor provides required information to the ACIS Identity Authority which confirms that the ACIS Applicant is employed and has a justifiable need for an ACIS Credential. The sponsor’s applicant information will include pertinent employment detail and documentation related to position, authorization, and level of access required. In the ACIS system, the sponsor role may be realized through the Airport Operator or Aircraft Operator that is acting as an ACIS Identity Authority in the system. The sponsor may also be a contractor or subcontractor to an Airport Operator or an Aircraft Operator, or an owner of a concession in an airport. The ACIS Sponsor has the responsibility to inform the ACIS Identity Authority of any change in the employment status of an employee it has sponsored in the system.

ACIS Sponsor Requirements REQ 3.3-1 The ACIS Sponsor shall designate an individual to act on the behalf of the sponsor as the

ACIS Sponsor’s Agent. REQ 3.3-2 The ACIS Sponsor’s Agent shall authorize ACIS credential enrollment requests for the

sponsor’s employees. REQ 3.3-3 The ACIS Sponsor’s Agent shall inform the ACIS Identity Credential Issuer of changes in

ACIS Participant employment status within a time specified by the ACIS Compliance Authority.

REQ 3.3-4 Upon termination of employment of an ACIS Participant, the ACIS Sponsor shall ensure that the terminated employee has returned his ACIS credential to the issuing ACIS Identity Authority.

3.3.2 ACIS Applicant

An ACIS applicant is an individual applying for an ACIS identity credential who is employed by an ACIS Sponsor in a capacity that requires access to federally regulated areas of an airport. The ACIS applicant will require sponsorship by their employer.


February 27, 2008

Page 32

ACIS Applicant Requirements REQ 3.3-5 ACIS Applicant shall provide biographic information to the ACIS Identity Authority as

specified in Appendix F, ACIS Applicant Enrollment Data. REQ 3.3-6 The ACIS Applicant shall provide fingerprint biometrics to the designated agent of the

ACIS Identity Authority as required to perform a CHRC. REQ 3.3-7 The ACIS Applicant shall provide identity source documents to the designated agent of

the ACIS Identity Authority as required to confirm the identity of the Applicant. REQ 3.3-8 The ACIS Applicant shall appear in-person at least once before the issuance of an ACIS

card.

3.3.3 ACIS Participant

An ACIS participant is an ACIS applicant that has successfully completed the ACIS enrollment and identity adjudication process, and has been issued a personalized ACIS identity credential. The ACIS Participant is responsible for following security rules of the ACIS Identity Authority. If the ACIS Participant’s ACIS card is lost or stolen, the ACIS Participant is responsible for immediately reporting the loss or theft to the ACIS Identity Authority and the ACIS Sponsor.

ACIS Participant Requirements REQ 3.3-9 If an ACIS credential is considered lost or stolen by its legitimate bearer, the ACIS

Participant shall immediately inform its sponsor as well as the issuing Identity Authority.

REQ 3.3-10 Upon Termination of employment of the ACIS Participant, the ACIS Participant shall immediately return his ACIS Credential to an agent of the Issuing Identity Authority.

3.3.4 ACIS Agent

ACIS Agents are ACIS Participants authorized by an ACIS authority to act in a trusted role to execute a task or process within the ACIS system on behalf of an ACIS system role. ACIS Agents provide individual accountability as well as organizational accountability for actions within the ACIS system. Through the use of audited digital signatures, created with the ACIS Agent’s private signing key on the Agent’s ACIS Credential, a high degree of transaction security and technical non-repudiation is achieved. This links the issued ACIS credential to the agent’s decisions executed during system operations, thereby enabling non-repudiation to strengthen the chain of trust throughout the system, including the enrollment, adjudication, creation and issuance of the ACIS credential itself.

ACIS Agent Requirements REQ 3.3-11 All ACIS Agent actions within the ACIS system that result in a change to ACIS Applicant

or ACIS Participant data or status shall be accompanied by the digital signature of the acting ACIS Agent.

REQ 3.3-12 ACIS Agent digital signatures within the ACIS system shall be created using the ACIS Agent’s private signing key stored in the ACIS Agent’s ACIS Credential.


February 27, 2008

Page 33

3.3.5 ACIS Identity Authority Roles

ACIS Identity Authorities are Aircraft Operators and Airport Operators acting as ACIS Credential issuers, based upon accreditation by the ACIS Compliance Authority (TSA). ACIS Identity Authority system roles include:

• ACIS Enrollment Manager; • ACIS Identity Adjudicator, and; • ACIS Identity Credential Issuer.

The ACIS Identity Authority designates a responsible individual to act as ACIS Issuer Security Coordinator. This individual is either the same individual designated under 49 CFR 1542 by the Airport Operator (49 CFR 1544 by the Aircraft Operator) to act as the Airport Security Coordinator (Aircraft Operator Security Coordinator) or an individual acting as a designate of the Airport Operator (Aircraft Operator). The ACIS Issuer Security Coordinator is responsible for overall operation of the ACIS Identity Authority, including maintaining accreditation of the ACIS Identity Authority. The ACIS Issuer Security Coordinator is also responsible for designating ACIS Participants to act in trusted ACIS Agent roles within the Identity Authority’s ACIS systems.

3.3.5.1 ACIS Enrollment Manager ACIS Identity Authority performs the role of the ACIS Enrollment Manager. The ACIS Enrollment Manager accepts enrollment authorizations for ACIS Applicants from the ACIS Sponsor who is the employer of the ACIS Applicant. The ACIS Enrollment Manager collects the required ACIS Applicant enrollment information submitted by an ACIS Applicant who has been sponsored by an ACIS Sponsor. Enrollment data includes the applicant’s biographic and the applicant’s biometric data. The ACIS Issuer Security Coordinator designates ACIS Participants to act as ACIS Enrollment Agents. The ACIS Enrollment Agent is the individual who initiates the chain of trust for identity proofing by confirming employer sponsorship, collecting applicant biometric data, binding the ACIS Applicant to their biometric, and validating and capturing digital images of the applicant’s identity-source documentation. The ACIS Enrollment Agent delivers a secured enrollment package, digitally signed by the ACIS Enrollment Agent’s ACIS credential to the ACIS Identity Adjudicator role for adjudication.

ACIS Enrollment Manager Requirements REQ 3.3-13 ACIS Enrollment Managers shall accept ACIS Applicant employment data (including

employee role, ACIS Access Level needed or employment status) data from ACIS Sponsors who are the employer of the ACIS Applicant.

REQ 3.3-14 ACIS Enrollment Managers shall accept ACIS Applicant biographic data from ACIS Applicant.

REQ 3.3-15 ACIS Enrollment Managers shall verify and capture digital images of ACIS Applicant supporting identity documents and capture ACIS Applicant biometric enrollment data.

3.3.5.2 ACIS Identity Adjudicator ACIS Identity Authority performs the role of the ACIS Identity Adjudicator. The ACIS Identity Adjudicator is responsible for providing two levels of adjudication of ACIS Applicants:


February 27, 2008

Page 34

• Adjudication of Federal Suitability of the ACIS Applicant under 49 CFR 1542 and 49 CFR 1544 for Airport and Aircraft Operators, respectively, using Federal Government Vetting Services;

• Adjudication of Local Suitability of the ACIS Applicant based upon local requirements of the ACIS Identity Authority and applicable State or Local regulation.

The ACIS Issuer Security Coordinator designates ACIS Participants to act as ACIS Adjudication Agents. ACIS Adjudication Agents are responsible for providing final suitability status determination of ACIS applicants for participation in ACIS under Federal rules as well as suitability under local suitability rules on behalf of the ACIS Identity Authority. The ACIS Adjudication Agent provides two distinct applicant status indicators to the Identity Authority’s ACIS Identity Credential Issuer role, separately indicating Federal Suitability and Local Suitability. It is important to maintain these two status indicators as it is possible that an ACIS applicant may be found suitable under Federal rules but found unsuitable under local rules. The ACIS Adjudication Agent will digitally sign these status indicators using the ACIS Adjudication Agent’s ACIS Credential. In cases where automated systems are used to support identity adjudication, status indicators may be digitally signed by an automated process, acting on behalf of the ACIS Identity Adjudicator role, assuming that the automated process is returning a determination that the ACIS Applicant is suitable. Negative determinations (disqualification of an applicant) must be digitally signed by the ACIS Adjudication Agent. In cases where an applicant is found suitable under Federal Rules but found unsuitable under Local rules, the Identity Authority will not issue an ACIS credential to the applicant. However, it is possible that this ACIS Applicant may be Locally Suitable under Local Suitability rules of a different Identity Authority. Rejection by an Identity Authority of an ACIS Applicant who is Federally suitable based upon disqualification under Local Suitability rules does not disqualify an individual from ACIS participation in other localities which may have differing rules. Because Local Suitability rules may vary across ACIS issuers, it is important to recognize that the ACIS credential, from the standpoint of ACIS trust, represents only Federal Suitability of the ACIS Participant globally within the ACIS scheme and the Local Suitability only provides a chain of trust for the Issuing Identity Authority (Airport or Aircraft Operator).

Identity Adjudicator Requirements REQ 3.3-16 ACIS Identity Authority shall perform the role of ACIS Identity Adjudicator. REQ 3.3-17 The ACIS Identity Adjudicator shall adjudicate Federal Suitability of the ACIS Applicant

based upon TSA STA status and adjudication of applicant’s FBI CHRC. REQ 3.3-18 The ACIS Identity Adjudicator shall provide separate adjudication status on ACIS

Applicants indicating Federal Suitability and Local Suitability to the ACIS Identity Credential Issuer.

REQ 3.3-19 The ACIS Identity Adjudicator shall digitally sign final adjudication status of ACIS Applicants using the private key of an ACIS certificate issued by the Identity Authority.

REQ 3.3-20 The ACIS Adjudication Agent shall digitally sign disqualifying adjudication status using the ACIS agent’s ACIS Identity Credential.

REQ 3.3-21 The ACIS Identity Adjudicator shall provide a redress process for rejected ACIS applicants.


February 27, 2008

Page 35

3.3.5.3 ACIS Identity Credential Issuer ACIS Identity Authority performs the role of the ACIS Identity Credential Issuer. The ACIS Identity Credential Issuer issues the ACIS credential to the ACIS Applicant after all identity proofing, background checks, and related approvals have been completed by the ACIS Enrollment Manager and the ACIS Identity Adjudicator. This role is responsible for collating the information collected for the creation of an Identity Credential including production of an ACIS card. Card production may be accomplished either locally or in a distributed manner, by the ACIS Identity Credential Issuer, or by a service provider of the ACIS Identity Credential Issuer provided that adequate security and quality control objectives for card stock management are fully met. The ACIS Issuer Security Coordinator designates an ACIS Participant to act as ACIS Approval Authority. The ACIS Approval Authority is responsible for establishing the organizational chain of command of the ACIS Identity Credential Issuer for authorization of issuance of ACIS Identity Credentials. This includes establishing approved ACIS Sponsors. The ACIS approval authority may designate automated or manual approval processes for issuance of ACIS credentials to eligible ACIS Applicants. The ACIS Approval Authority is responsible for management of any ACIS Certificates and private keys used by automated or manual processes to support Identity Credential Issuance. These processes include signing of ACIS credential data (Attribute Authority certificates and signing keys) and issuance and revocation of ACIS certificates (ACIS Registration Authority certificates and signing keys).

ACIS Identity Credential Issuer Requirements REQ 3.3-22 ACIS Identity Credential Issuers shall issue ACIS Identity Credentials to qualifying ACIS

Applicants (ACIS Participants). REQ 3.3-23 ACIS Identity Credential Issuers shall accept updates to ACIS Participant employment

status from ACIS Sponsors. REQ 3.3-24 ACIS Identity Credential Issuers shall update ACIS Participant identity data received

from ACIS Sponsors and ACIS Applicants. REQ 3.3-25 ACIS Identity Credential Issuers shall update, re-issue or revoke ACIS Identity

Credentials based upon changes to ACIS Participant identity data received from ACIS Sponsors.

REQ 3.3-26 ACIS Identity Credential Issuers shall accept changes to ACIS Participant STA status from TSA.

REQ 3.3-27 ACIS Identity Credential Issuers shall revoke ACIS Identity Credentials if STA status change indicates the ACIS Participant is no longer eligible.

REQ 3.3-28 ACIS Identity Credential Issuers shall report changes in ACIS Participant suitability to TSA.

REQ 3.3-29 The ACIS Identity Credential Issuer shall practice best practices for separation of roles and responsibilities according to risk.

REQ 3.3-30 The ACIS Identity Credential Issuer shall ensure the system has at least two persons performing different functions in the chain of trust processes.

REQ 3.3-31 The ACIS Identity Credential Issuer shall enforce the principle of separation of duties to ensure that no single individual has the capability to issue an ACIS credential without the participation of another authorized person.


February 27, 2008

Page 36

3.3.6 Access Control Authority Roles

ACIS Access Control Authorities are Airport Operators who are responsible for managing airport security and physical access control systems. The ACIS Access Control Authority is responsible for access control decisions made on its physical premises. The ACIS Access Control Authority role may also be performed by Airport Tenants and Aircraft Operator Exclusive Area Operators who are operating subordinate to an Airport Operator under a TSA approved security program. ACIS Access Control Authority system roles include:

• ACIS Privilege Issuer, and; • ACIS Physical Access Control System (PACS) Operator.

The ACIS Access Control Authority is responsible for granting or denying (revoking) access privileges to an ACIS participant relative to a given perimeter under its authority. In all cases where the ACIS Access Control Authority is an Airport Operator, the ACIS Access Control Authority is also an ACIS Identity Authority. It is important to maintain a clear distinction between these authorities from a functional standpoint, since each role requires the use of very different data types (e.g. personally identifiable information), and follows very different processes. The Airport Security Coordinator (49 CFR 1542) is responsible for overall operation of the ACIS Access Control Authority, including maintaining accreditation of the ACIS Access Control Authority. The ACIS Airport Security Coordinator is also responsible for designating ACIS Participants to act in trusted ACIS agent roles within the ACIS elements of the Access Control Authority’s systems. An ACIS participant (having an ACIS credential) is not automatically granted physical access privileges to any area under the control of the ACIS Access Control Authority. ACIS credential does not provide access to any area unless the privilege for access has been granted to the individual by the Access Control Authority at a given location.

3.3.6.1 ACIS Physical Access Privilege Issuer The ACIS Access Control Authority performs the role of ACIS Physical Access Privilege Issuer. The Physical Access Privilege Issuer is responsible for control of the secure entry to a facility, or a particular regulated or restricted area of an airport, through the management (issuance and revocation) of access privileges. The ACIS Physical Access Privilege Issuer will use the ACIS identity credential issued by an ACIS Identity Authority to authenticate an ACIS participant’s identity, and perform subsequent access grant or deny decisions. The Airport Security Coordinator designates ACIS Participants to act as ACIS PACS Registration Agents. ACIS PACS Registration Agents are responsible for registering ACIS Participants in the Access Control Authority’s PACS and verifying the identity of the ACIS Participant prior to PACS registration using the ACIS Identity Credential. Typically, each Airport will be an ACIS Physical Access Privilege Issuer and will apply its established airport security program to grant access privileges to ACIS Participants. The ACIS Identity Credential will be used by Airport Operators to authenticate the identity of an individual prior to granting access privileges to that individual. The ACIS Privilege Credential will be enabled in a later phase to support automated secure PACS behavior.


February 27, 2008

Page 37

The ACIS access privilege issuance is completely independent of the ACIS credential issuance. It is possible that an ACIS participant would be issued several access privileges or no access privileges at all. For example, an ACIS Agent acting as an ACIS Adjudication Agent may never need access to a sterile or SIDA area in any airport.

ACIS Physical Access Privilege Issuer Requirements REQ 3.3-32 ACIS Physical Access Privilege Issuer shall support registration of ACIS participants

into local airport Physical Access Control Systems (PACS). REQ 3.3-33 The Airport Security Coordinator shall designate ACIS Participants to act as ACIS PACS

Registration Agents. REQ 3.3-34 ACIS PACS Registration Agents shall use the ACIS Identity Credential to authenticate

the identity of an ACIS Participant prior to registration of an ACIS Participant into a local airport PACS.

REQ 3.3-35 ACIS Physical Access Privilege Issuers shall validate that the ACIS Identity Credential of an ACIS Participant has not been revoked prior to registration of an ACIS Participant into a local airport PACS.

REQ 3.3-36 ACIS Privilege Issuer may issue local access privileges (identifiers, attributes and cryptographic keys) to the ACIS Credential (ACIS Phase III).

Note: ACIS Physical Access Privilege Issuer will grant access privileges to authenticated ACIS cardholders based upon local Access Control Authority security requirements.

3.3.6.2 ACIS Physical Access Control System (PACS) Operator The ACIS Access Control Authority performs the role of ACIS PACS Operator. The ACIS PACS Operator is in charge of providing access control services to a given protected area. This includes access control for people, but also all the security services such as cameras, detection systems, door locks and alarms of various kinds. The ACIS PACS Operator may accept a privilege credential issued by the ACIS Physical Access Privilege Issuer or an identity credential issued by an ACIS Identity Authority as a basis for making access control decisions. Acceptance of either credential for any access control decision is entirely under the authority of the ACIS PACS Operator, based upon the local security program. It is possible for the PACS Operator to utilize ACIS Identity Credentials as access tokens using an identity based authentication. In ACIS Phase II, use of the ACIS Identity Credential can support electronic and biometric identity verification (e.g. using handheld devices) to strengthen SIDA Challenge. For use in access control, the ACIS Identity Credential is intended primarily for ACIS Participants having to access an area occasionally or on an exception basis or for general access categories where the ACIS Identity Credential may convey implicit privileges under the Airport Security Program. To support identity-based access control, the PACS must be able to verify the authenticity of the ACIS Identity Credential and the cardholder (similar function as for registration access privilege granting) and allow access under the conditions specified by the airport security program.

ACIS Physical Access Control System Operator Requirements REQ 3.3-37 ACIS PACS Operators may use the ACIS Privilege Credential with locally issued and

managed access privileges as an ACIS privilege-based access control token.


February 27, 2008

Page 38

REQ 3.3-38 ACIS PACS Operators may use the ACIS Identity Credential for identity-based authentication at physical access control points.

REQ 3.3-39 If an ACIS PACS Operator uses the ACIS Identity Credential as a physical access control token, the PACS shall use smart card and biometric devices and processes approved by the ACIS Compliance Authority for identity-based authentication.

REQ 3.3-40 If an ACIS PACS Operator uses the ACIS Privilege Credential as a physical access control token, the PACS shall use smart card and biometric devices and processes approved by the ACIS Compliance Authority for privilege-based authentication.

REQ 3.3-41 ACIS PACS Operators shall periodically verify that the ACIS Identity Credential has not been revoked.

REQ 3.3-42 ACIS PACS Operators shall revoke ACIS Participant access privileges if the ACIS Participant’s Identity Credential has been revoked.

3.4 TSA ACIS Program Federal Roles TSA ACIS Program Federal roles include ACIS system roles necessary to establish a chain of trust between ACIS Entities. ACIS Federal Roles include the following:

• ACIS Compliance Authority; • ACIS Central Status Provider, and; • ACIS Certificate Authority Provider.

3.4.1 ACIS Compliance Authority

TSA acts as the ACIS Compliance Authority. The ACIS Compliance Authority serves as the principal organizational authority of the ACIS system to establish and maintain the specifications required for ACIS system interoperability and data management. The ACIS Compliance Authority is responsible to manage compliance of ACIS products and services to ACIS specifications and to accredit all ACIS entities acting in ACIS system roles. In addition to technical specifications, the ACIS Compliance Authority will establish ACIS common policies in order to have compatible ACIS processes and support transferable levels of security assurance and trust between entities. The ACIS Compliance Authority will also assist other ACIS system entities in implementation of complaint ACIS systems by establishing accredited ACIS Shared Service Providers to perform all of the Identity Authority Services required in the ACIS system. ACIS Shared Service Providers will be based upon existing PIV service providers including Federal PKI Shared Service Providers and GSA PIV Shared Service Providers as well as PIV-aligned service providers such as FiXs, the Federation for Identity Cross Credentialing Systems. Use of a Shared Service Provider approach will provide ACIS Identity Authorities a cost effective means to issue ACIS credentials and avoid high cost of duplicate system accreditation by ACIS Entities.

ACIS Compliance Authority Requirements REQ 3.4-1 The TSA shall perform the role of ACIS Compliance Authority. REQ 3.4-2 The ACIS Compliance Authority will establish ACIS technical specifications for ACIS

system elements (Products and Services). REQ 3.4-3 The ACIS Compliance Authority will establish ACIS qualification processes for ACIS

system elements (Products and Services).


February 27, 2008

Page 39

REQ 3.4-4 The ACIS Compliance Authority will establish an ACIS accreditation process for ACIS Identity Authorities.

REQ 3.4-5 The ACIS Compliance Authority will establish an ACIS accreditation process for ACIS Access Control Authorities.

REQ 3.4-6 The ACIS Compliance Authority will establish ACIS common policies for participating ACIS Entities.

REQ 3.4-7 The ACIS Compliance Authority will monitor ACIS compliance of participating ACIS Entities.

REQ 3.4-8 The ACIS Compliance Authority will establish processes and agreements with Government Vetting Sources necessary to support vetting of ACIS Participants against Federal Government data sources.

3.4.2 ACIS Central Status Provider

TSA acts as the ACIS Central Status Provider. The ACIS Central Status Provider is responsible for aggregating requests and responses for Federal Vetting Services made by ACIS Identity Authorities. This aggregation includes facilitation of STA requests to the TSA and CHRC requests to the FBI. The ACIS Central Status Provider returns STA status and CHRC responses to the requesting ACIS Identity Authority to support adjudication of ACIS Applicants by the ACIS Identity Authority. As a part of this process, the ACIS Central Status provider performs a biometric duplicate check, a 1:n biometric search of applicant fingerprint records against a database of ACIS Participants and previous ACIS Applicants, in order to positively associate requests from multiple ACIS Identity Authorities for applicants who are the same person. The ACIS Central Status Provider maintains a centrally generated index to this person which associates requests from multiple identity authorities for this person. This biometric search is important in detecting ACIS Applicants who may be using a fraudulent identity and to support cascaded revocation of all Identity Credentials issued to a person, should an associated threat be detected by TSA or if an Identity Authority becomes aware of situations that repudiate an ACIS Participants suitability to be an ACIS Participant. In order to avoid privacy risks associated with centralized identity databases, the ACIS Central Status Provider will not receive or store Identity Authority local identifiers for the ACIS Applicant or Participant and will not store applicant biographic data, except as required temporarily to support aggregation of vetting requests and responses.

ACIS Central Status Provider Requirements REQ 3.4-9 The TSA shall perform the role of ACIS Central Status Provider. REQ 3.4-10 The ACIS Compliance Authority will establish systems to facilitate identity data

interchange between Government Vetting Sources and ACIS Identity Authorities. REQ 3.4-11 The ACIS Compliance Authority will establish systems to perform 1:n biometric search

(biometric duplicate check) of ACIS Applicant biometrics against all current and previous ACIS Participants and previous ACIS Applicants whose biometric data is still retained based upon ACIS PIA data retention rules.

REQ 3.4-12 The ACIS Central Status Provider shall not retain ACIS Applicant biographic data except as required to complete requests for applicant vetting.

REQ 3.4-13 The ACIS Central Status Provider shall not accept or store local person identifiers assigned to ACIS Applicants and ACIS Participants by ACIS Identity Authorities


February 27, 2008

Page 40

3.4.3 ACIS Certificate Authority Provider

TSA acts as the ACIS Certificate Authority (CA) Provider. The ACIS Certificate Authority Provider has the responsibility to establish a hierarchical Public Key Infrastructure (PKI) for the ACIS system based upon Federal PKI Common Policy. The ACIS Certificate Authority Provider is responsible for establishing and maintaining an ACIS Root CA along with PKI Shared Service Providers to support issuance of ACIS certificates by ACIS Identity Authorities. ACIS PKI Shared Service Providers will be accredited Federal PKI Shared Service Providers. Use of ACIS PKI Shares Service Providers is mandatory for ACIS Identity Authorities issuing ACIS certificates, in order to establish a common basis of trust in all certificates issued to ACIS Participants. The ACIS PKI Shared Service Providers will support Certificate Authority and Validation Authority systems that are compliant with Federal PKI Common Policy and issue CRL’s and certificates that conform to FPKI Shared Service Provider certificate profiles. The ACIS PKI will be architected as a simple hierarchical PKI architecture. The ACIS Certificate Authority Provider will establish a self-signed root CA to act as the trust anchor within the ACIS PKI. Upon accreditation of ACIS Identity Authorities, the ACIS Certificate Authority Provider’s ACIS Root CA will sign the subordinate CA certificate of the Identity Authority’s ACIS Subordinate CA. This Subordinate CA “issuance” by the ACIS Root CA delegates authority to the accredited ACIS Identity Authority to issue ACIS certificates. It is important to note that the use of the ACIS PKI Shared Service Providers provides a separate and independent Certificate Authority for each ACIS Identity Authority with CA private signing key under the authority of the ACIS Identity Authority as an outsourced service. This structure allow ACIS relying parties either to trust ACIS certificates globally, through trust of the ACIS CA root certificates, or locally, by relying only on certificates issued by a specific subordinate CA.

ACIS Certificate Authority Provider Requirements REQ 3.4-14 The TSA shall perform the role of ACIS Certificate Authority Provider. REQ 3.4-15 The ACIS Certificate Authority Provider shall establish an ACIS PKI. REQ 3.4-16 The ACIS Certificate Authority Provider shall act as the ACIS Root CA. REQ 3.4-17 The ACIS PKI shall comply with Federal PKI Common Policy. REQ 3.4-18 The ACIS Certificate Authority Provider shall establish accredited ACIS PKI Service

Providers for use by ACIS Identity Authorities. REQ 3.4-19 The ACIS PKI Shared Service Providers shall issue certificates that conform to Federal

PKI Shared Service Provider certificate profiles. REQ 3.4-20 The ACIS Certificate Authority Provider will support delegation of ACIS Identity

Credential issuance authority by the ACIS Compliance Authority to accredited ACIS Identity Authorities through signing of Identity Authority Subordinate CA certificates using the ACIS Root CA private key.

REQ 3.4-21 The ACIS Certificate Authority Provider will establish and validate trust of ACIS Identity Authorities to accredited ACIS Access Control Authorities.


February 27, 2008

Page 41

3.5 ACIS System Elements ACIS System Elements comprise ACIS system components and ACIS Agents who are actors in the ACIS System who interact to implement ACIS System Roles. ACIS System Elements fall into three major categories, based upon the ACIS authority that is responsible for implementing the associate system roles. Top-level categories of ACIS System are depicted in ��HFigure 3-3 ACIS System Components and Agents.

Applicant Enrollment Data

Credential Status Validation

PACS/Card Mutual Registration

Employment Status Change

Extended Vetting Data

Identity or Privilege Verification

ACIS Credential Issuance

Criminal History and Threat AssessmentStatus

ACIS EmployersACIS Identity Authorities

(Aircraft and Airport Operators)ACIS Identity Authorities(Aircraft and Airport Operators)

ACIS Employers

ACIS Sponsor


TSA ACISProgram

ACIS Central Service Provider Systems

ACIS PKI

ACIS CSMS

ACIS Access Control Authorities(Airport Operators)ACIS Access Control Authorities

(Airport Operators)

ACIS Access Control Authorities

State, Local and Commercial Vetting

SourcesState, Local and

Commercial Vetting SourcesExtended Vetting

Services

Sponsor’s Agent


FBICHRC TSA

STA

STA Adjudicator

ACIS Applicant

Identity Adjudication SystemAdjudication Agent

Enrollment Request

Card Production

Card Management

EnrollmentIDMSEnrollment Agent

Approval Authority

Access Granting

Privilege Granting

Privilege Revocation

PACS Registration

Identity Verification

Privilege Verification

ACIS Access Control System Elements

Airport Physical Access Control System

PACS Registration Agent

Identity StatusNotification

ACIS Credential

ACISParticipant

(“Cardholder”)

Airport Security Coordinator

Issuer Security Coordinator

Identity Vetting and Certificate Requests

ACIS CredentialIssuance System Elements

PACS Status Validation

ACIS System Components

Federal Entities


Figure 3-3 ACIS System Components and Agents

3.5.1 ACIS Credential Issuance System Elements

The ACIS Credential Issuance System components are based upon the PIV system-based model. The PIV system-based model requires the use of an automated Identity Management System to manage applicant and participant identity data. This alignment provides a basis to establish


February 27, 2008

Page 42

uniform processes for ACIS identity vetting and credential issuance and to provide uniform standards for privacy and security assurance upon which trust in an ACIS credential is based. Alignment with the PIV system-based model also allows the ACIS Credential Issuance System to be technically aligned with and leverage providers complying with the PIV Shared Service Provider (SSP) shared component architecture. It is the intent of this specification that the ACIS Identity Credential Issuance System should allow Identity Authorities to outsource any or all ACIS Identity Credential Issuance System Components to ACIS Shared Service Providers. ACIS Shared Service Providers can be implemented by PIV compliant service providers with relatively small changes to the PIV SSP model. It is important to note that the PIV SSP model was developed to help smaller Federal Agency deploy PIV credentials while avoiding the large infrastructure investment required to directly implement a PIV compliant credential issuance system. For all but the largest ACIS Identity Authorities, the cost to directly integrate, deploy and accredit an ACIS Credential Issuance System will likely be prohibitive. For this reason, TSA will accredit ACIS Shared Service Providers for Identity Credential System Roles, except as noted in section ��H3.5.1.3, ��HIdentity Adjudication System (IAS). ACIS Identity Authorities are encouraged, but not required to use ACIS Shared Service Providers to implement most Identity Authority roles. ACIS Identity system components comprise the following system elements;

• Enrollment System; • Identity Management System; • Identity Adjudication System; • Card Management System; • Card Production System.

These elements are described in the following sections.

3.5.1.1 Enrollment System The ACIS Enrollment System supports enrollment of ACIS Applicants using enrollments stations. An applicant enrolls at an enrollment station only after the applicant’s sponsor affiliation is determined, and the sponsor authorizes enrollment. Enrollment stations facilitate identity proofing of applicants in accordance with ACIS Specifications and capture digital images of I-9 documentation. Applicant biometric samples are captured including facial image and 10-slap fingerprints. The information captured is used for ACIS identity adjudication and ACIS credential issuance. Each enrollment station consists of the following components:

• Digital camera; • Fingerprint scanner; • Document scanning and authentication device; • Smart card reader, and; • Computer.

Enrollment systems interface with the ACIS IDMS to receive and send applicant information. The Enrollment System retrieves applicant information from the ACIS IDMS, including


February 27, 2008

Page 43

authorization to enroll. In addition, the Enrollment System sends all enrollment data back to the IDMS for identity vetting and adjudication. An ACIS Enrollment Agent facilitates capture of documents and biometrics, as necessary. The ACIS Enrollment System may be hosted by the Identity Authority directly or provided by an external service provider

ACIS Enrollment System requirements REQ 3.5-1 The ACIS Enrollment System shall utilize enrollment system components listed on the PIV

approved products list with modifications as necessary to support ACIS Requirements.

3.5.1.2 Identity Management System (IDMS) The IDMS is the central component of the ACIS Credential Issuance System that interacts either directly or indirectly with all other components of the ACIS Credential Issuance System. The IDMS receives enrollment requests from the ACIS Applicant’s Sponsor and applicant biographic data from the ACIS Applicant. Applicant Enrollment data (identity proofing information and biometric data) is received from the ACIS Enrollment System following applicant enrollment. Upon receipt of applicant enrollment data, a complete enrollment package is forwarded to the ACIS Identity Adjudication System. Upon return of a successful suitability determination from the Identity Adjudication System, the ACIS IDMS creates signed data objects including Cardholder Unique ID (CHUID) and biometric templates and forwards identity credential data to the ACIS Card Management System to initiate card issuance and card lifecycle management. The ACIS IDMS may be hosted by the Identity Authority directly or provided by an external service provider

ACIS IDMS Requirements REQ 3.5-2 The ACIS IDMS shall utilize an IDMS product listed on the PIV approved products list

with modifications as necessary to support ACIS Requirements.

3.5.1.3 Identity Adjudication System (IAS) The ACIS Identity Adjudication System (IAS) is a system or service supporting adjudication of Federal Suitability and Local Suitability of ACIS Applicants by the ACIS Identity Adjudicator role. The identity adjudication system facilitates adjudication of ACIS Applicants by ACIS Adjudication Agents by presenting data from Federal Vetting Sources (federal suitability information) and Extended Vetting Sources (local suitability information) for evaluation against disqualifying offenses or background criteria. The ACIS Identity Adjudication System initiates a case for adjudication upon receipt of ACIS Applicant Enrollment data from the ACIS IDMS. The Identity Adjudication System collates the results of the IDMS initiated background checks for Applicant suitability determination. The ACIS Identity Adjudication System may automate comparison of ACIS Applicant background data to federal or local disqualifying offenses or criteria. If disqualifying offenses or criteria are recognized by the automated process, the Identity Adjudication system forwards the automated comparison results to an ACIS Adjudication Agent for final disposition of suitability.


February 27, 2008

Page 44

The ACIS Identity Adjudication System will separately maintain suitability criteria for federal and local suitability determination and provide a composite suitability status to the ACIS IDMS, separately indicating federal and local suitability of the ACIS Applicant. The ACIS Identity Adjudication System will ensure that the composite suitability status returned is digitally signed by the ACIS Adjudication Agent who is responsible for determination of Applicant suitability. The ACIS Identity Adjudication system may also provide automated services to facilitate management of waiver and redress processes for ACIS Applicants. This may include management of notifications to rejected applicants or tracking status of waiver and appeals processes. Due to the sensitive nature of the background investigation information managed by the identity adjudication system, the ACIS Identity Adjudication System will maintain strict control of access to adjudication information by ACIS Adjudication Agents and authorized Identity Authority personnel. The ACIS Identity Adjudication System may be hosted by the Identity Authority directly or provided by an external service provider

3.5.1.4 Card Management System (CMS) The ACIS Card Management System is a system or service managing the life-cycle of cards and card-applications, keeping track of issued cards, their status, content and legitimate user identifier from card activation through card termination. The ACIS CMS may be hosted by the Identity Authority directly or provided by an external service provider.

ACIS CMS Requirements REQ 3.5-3 The ACIS CMS shall utilize a CMS product listed on the PIV approved products list with

modifications as necessary to support ACIS Requirements.

3.5.1.5 Card Production System (CPS) The ACIS Card Production System is a system or service which loads the ACIS card-application(s) and related data as well as applying the visual features (printing) and physical security features on the card. The ACIS CPS may be hosted by the Identity Authority locally or provided by an external service provider.

ACIS CPS Requirements REQ 3.5-4 The ACIS CPS shall utilize CPS products and/or services listed on the PIV approved

products list with modifications as necessary to support ACIS Requirements.

3.5.2 ACIS Access Control System Elements

Airport Access Control Systems operate under the authority of the Airport Operator (ACIS Access Control Authority) subject to an approved Airport Security Program. The Local Airport PACS incorporates ACIS compliant systems (components) to support use of the ACIS Credential for Identity-based verification and Privilege-based verification. ACIS PACS Subsystems include:

• Identity Verification System; • PACS Registration System;


February 27, 2008

Page 45

• PACS Status Validation System, and; • Privilege Verification System.

3.5.2.1 Identity Verification System The Identity Verification system is handheld or desktop computer system used to very the identity of an ACIS cardholder. The Identity Verification subsystems incorporate biometric reader, smart card reader and PIN entry devices compliant with PIV requirements. The Identity Verification System supports graduated levels of cardholder identity credential verification assurance, using a combination of ACIS Card PIN, ACIS Card Authentication and ACIS cardholder biometric verification in both attended an unattended applications. Graduated assurance levels allow varying levels of assurance to be applied in identity verification based upon threat, risk and impact levels associated with various access control scenarios. The ACIS Identity Verification System supports the following identity verification assurance levels:

• Level 1 Identity Verification (card authentication); • Level 2 Identity Verification (card authentication with card PIN verification); • Level 3 Identity Verification (card authentication with card PIN and fingerprint biometric

verification), and; • Level 3 Attended Identity Verification (card authentication with card PIN and digital

facial image comparison by attendant).

The Identity Verification System is intended to be a generic system component within ACIS. The Identity Verification System may be a standalone system or may be incorporated as a component (subsystem) of an airport PACS. The Identity Verification System may also be used as a generic functional component in any ACIS system requiring Identity-based verification, such as verification of an ACIS Enrollment Agent prior to granting access to an ACIS Enrollment System (Logical Access Control).

ACIS Identity Verification System Requirements REQ 3.5-5 The ACIS Identity Verification System shall utilize components listed on the PIV

Approved Products List with modifications necessary to support the ACIS Identity Credential.

REQ 3.5-6 The ACIS Identity Verification System shall support cardholder verification using the ACIS Identity Credential.

3.5.2.2 PACS Registration System The PACS Registration Subsystem performs registration of ACIS Identity Credentials in the PACS prior to granting PACS privileges to an ACIS Participant. As a part of the PACS registration process, Level 3 Identity Verification of the ACIS Participant is performed in order to transfer trust in the ACIS Identity to the PACS. Use of Level 3 Identity Verification allows local PACS identifiers (e.g. local PACS badge, privilege number or operational biometric) to be used by the PACS at identity assurance levels up to the assurance level in the underlying ACIS Identity. In ACIS Phase III, in addition to registering the ACIS Identity Credential in the PACS, the PACS Registration System registers PACS local identifiers (privilege number) and keys in the ACIS Card. This registration in the ACIS credential is supported by the ACIS Privilege Card-


February 27, 2008

Page 46

Application resident in the ACIS ICC chip. This mutual registration allows the ACIS Card to be used by the PACS as a local access control token with card authentication and biometric verification of the ACIS cardholder. Registration of local keys in the ACIS Card allows strong mutual authentication between the ACIS Card and the PACS using efficient symmetric key cryptography protecting card data (e.g. biometric templates) from unauthorized access without the use of a Card PIN. In ACIS Phase III, the Privilege Card-Application also allows Airport PACS to register local identifiers and keys in ACIS Cards issued by other Identity Authorities (with authorization by the issuing ACIS Identity Authority). This allows Access Control Authorities to grant access privileges to transient personnel (e.g. Flight Crew) without the need to issue a new (and duplicative) card to transient personnel.

PACS Registration System Requirements REQ 3.5-7 The ACIS PACS Registration System shall register ACIS Identity Credentials in the

PACS. REQ 3.5-8 The ACIS PACS Registration System shall perform ACIS Level 3 Identity Verification

prior to registration of an ACIS Participant in the PACS. REQ 3.5-9 The ACIS PACS Registration System shall register local PACS identifiers and keys in the

ACIS Card (ACIS Phase III).

3.5.2.3 PACS Status Validation System The PACS Status Validation System performs validation of ACIS Identity Credentials previously registered in the PACS. The PACS Status Validation System uses either OCSP or CRL to periodically check for revocation of ACIS Identity Credentials. Upon recognizing that the registered ACIS Identity Credential has been revoked, the PACS can automatically revoke access privileges associated with the ACIS Participant.

PACS Status Validation System Requirements REQ 3.5-10 The ACIS PACS Status Validation System shall periodically validate ACIS Identity

Credentials Registered in the PACS. REQ 3.5-11 The PACS Status Validation system shall validate ACIS Identity Credential using either

OCSP or CRL.

3.5.2.4 Privilege Verification System The PACS Privilege Verification Systems are contact or contactless biometric physical access control readers supporting functions of the ACIS Privilege Credential. This includes functions needed for ACIS Cardholder verification at access points managed by an Airport PACS. The reader could be in several discrete components or one integrated PACS reader. The functions supported by the reader include reading of contact or contactless badges, obtaining biometric samples, and/or entering PACS PINs. As with the ACIS Identity Verification system, ACIS Privilege Verification Systems support graduated levels of cardholder verification. As compared to the ACIS PIV-Aligned Identity Verification System, the ACIS Privilege Verification System provides additional flexibility in verification modes using either contact or contactless PACS readers, protecting Participant biometric data through mutual authentication and session encryption without the need for a Card


February 27, 2008

Page 47

PIN. This allows use of a locally controlled PACS PIN for cardholder verification as well as the use of biometric verification either with or without a PACS PIN. Privilege Verification System cardholder verification assurance levels include:

• Level 1 Card Privilege Verification (card authentication); • Level 2 Card Privilege Verification (card authentication with PACS PIN); • Level 2 Biometric Privilege Verification (card authentication with fingerprint biometric

verification); • Level 2 Attended Privilege Verification (card authentication with manual digital facial

image comparison), and; • Level 3 Biometric Privilege Verification (card authentication with fingerprint biometric

verification and PACS PIN).

Privilege Verification System Requirements REQ 3.5-12 The ACIS Privilege Verification System shall support cardholder verification using the

ACIS Privilege Card-Application (ACIS Phase III).

3.5.3 ACIS Central Service Provider System Elements

ACIS Central Service Provider Systems include: • ACIS Central Status Management System, and; • ACIS Public Key Infrastructure (PKI).

3.5.3.1 ACIS Central Status Management System (CSMS) The ACIS Central Status Management System is an ACIS system/service implementing the ACIS role of ACIS Central Status Provider. The ACIS Central Status Management System supports aggregation of Federal Vetting requests for STA and CHRC received from the IDMS of ACIS Identity Credential Issuers and returns STA and CHRC results to the requesting IDMS. The CSMS maintains fingerprint biometrics of ACIS Participants and rejected ACIS Applicants in order to support AFIS search of Applicants and biometrically check for duplicate applications from the same individual. Biometric matches may normally occur if a legitimate ACIS Participant applies for ACIS participation with multiple ACIS Identity Authorities. Biometric matches may also indicate fraudulent applications (e.g. previously reject Applicant applying under a false name). When biometric matches are recognized by the ACIS CSMS, the CSMS forwards the matches to the TSA Screening Gateway for duplicate resolution as a part of the STA request. Upon completion of the STA, the SCMS assigns a unique CSMS Index (global ACIS person identifier) to the ACIS Applicant. The ACIS SCMS Index is returned to the requesting IDMS along with STA and CHRC results. The SCMS Index acts as an index to all ACIS Identity Authorities who have issued ACIS credentials to the same individual. The SCMS index is only used for subsequent communication of status of the Applicant (or Participant) between the SCMS and the IDMS. The SCMS Index is not stored on the ACIS credential and the IDMS assigned person identifier associated with the ACIS Participant is not communicated to the SCMS. This approach of using a global SCMS identifier that is separate from the IDMS assigned person identifier is an important mechanism to protect privacy of ACIS Participants,


February 27, 2008

Page 48

since the SCMS identifier cannot be used to track an individual based upon information contained in the ACIS credential. Upon completion of identity adjudication by the ACIS Identity Authority, the Identity Authority returns the adjudication status (suitable or unsuitable) to the SCMS. The SCMS maintains the status of each Participant or rejected Applicant to support resolution of AFIS matches and global revocation of ACIS Participants as required. Participation in ACIS may be revoked due to changes in the suitability of an ACIS Participant. Change in suitability may be recognized by the issuing ACIS Identity Authority or by the TSA. Changes in suitability my indicate unsuitability under federal or local suitability rules. Suitability changes are reported to the SCMS either by the TSA or by the issuing Identity Authority. If the suitability status change indicates that a Participant is unsuitable under federal rules, the SCMS will report the suitability change to all Identity Authorities (and the TSA, unless they initiate the suitability status change) using the CSMS Index of the person. The notified Identity Authorities will take action to confirm the status change and if confirmed, will revoke the Participant’s ACIS Credential.

3.5.3.2 ACIS Public Key Infrastructure (PKI) The ACIS PKI is an ACIS shared service providing certificate issuance and management services for ACIS authorities. The PKI components shall be hosted by an ACIS PKI Shared Service Provider. The ACIS PKI will issue digital Certificates for ACIS credentials for the following keys define in PIV.

• PIV Authentication Key - The PIV Authentication Key as defined in FIPS 201 is used to authenticate the card and cardholder using the Personal Identification Number (PIN).

• Card Authentication Key - This key and certificate if the key is an asymmetric key supports PIV Card Authentication for device to device authentication purposes. Cardholder consent is not required to use this key. The access rule for PKI cryptographic functions is “Always”. Where the Card Authentication Key is a symmetric key, the CHUID authentication key map shall be present and specify the cryptographic algorithm and key storage location.

• Digital Signature Key - This key and certificate supports the use of digital signatures for the purpose of document signing. The Public Key Infrastructure (PKI) cryptographic function is protected with a “PIN Always” access rule. This requires cardholder participation every time the key is used for digital signature generation.

• Key Management Key - This key and certificate supports the use of encryption for the purpose of confidentiality. This key pair is escrowed by the issuer for key recovery purposes. The PKI cryptographic function is protected with a “PIN” access rule. This requires cardholder activation, but enables multiple compute operations without additional cardholder consent.

Refer to Section 4, ACIS Chain of Trust for addition description of the ACIS PKI.


February 27, 2008

Page 49

ACIS PKI Requirements REQ 3.5-13 ACIS PKI Services shall comply with the X.509 Certificate Policy for the U.S. Federal

PKI Common Policy Framework, Version 2.5 16 October 2006 REQ 3.5-14 ACIS PKI Services shall comply with the Federal Identity Credentialing Committee

Shared Service Provider Subcommittee X.509 Certificate and Certificate Revocation List (CRL) Extensions Profile for the Shared Service Providers (SSP) Program, Version 1.3, February 6, 2006.


February 27, 2008

Page 50

4 ACIS Chain of Trust The ACIS system is designed to assure that an issued ACIS credential is securely linked to the trusted individual to whom it is issued. The ACIS trust model establishes a secure chain of trust between the ACIS Sponsor, the ACIS Applicant, the ACIS Credential Issuer, the ACIS Participant holding an ACIS Credential and ACIS relying parties (ACIS Identity Authorities and ACIS Access Control Authorities) who trust the ACIS Credential to make identity verification and access control decisions. The foundation of trust in the ACIS credential, for ACIS relying parties is based upon compliance of ACIS roles and components operating within the ACIS policy and technical framework along with accreditation of ACIS authorities acting in those ACIS roles. The technical framework for the ACIS chain of trust is based upon:

• The ACIS PKI, and; • Linkage of ACIS Revocable Elements through the ACIS Central Status Management

System (CSMS).

4.1 ACIS PKI Chain of Trust The ACIS PKI provides the foundation of the chain of trust within the ACIS System. The ACIS PKI is implemented as a hierarchical Certificate Authority (CA) architecture, with a TSA Root CA as the ACIS Trust Anchor. Identity Authority CAs, operate as subordinate CAs the ACIS TSA root, under the role of ACIS Identity Credential Issuers. ACIS CAs are implemented as accredited Federal PKI Compliant PKI Shared Service Providers (FPKI SSP). Implementation of ACIS CAs as accredited PKI Shared Service Providers assures interoperability and consistency of certificate policy between ACIS Identity Authorities and consistent security assurance critical to relying party’s trust in ACIS certificates from all ACIS certificate issuers. The use of accredited FPKI SSPs also ensures consistency of certificate profiles, Certificate Revocation Lists (CRL) and online certificate validation services, also critical to transfer of trust from ACIS Identity Authorities to ACIS relying parties. Additionally, ACIS compliance with Federal PKI Common Policy and Shared Service Provider certificate and CRL profiles establishes a technical framework for future reliance on other non-ACIS PIV-Aligned credentials (e.g. Federal Agency Credentials). Note that reliance on non-ACIS credentials or cross certification of ACIS with the Federal PKI is outside the scope of this specification. 4.1.1 TSA ACIS Root CA

The TSA Root CA generates a self-signed root CA certificate and acts as the trust anchor for the ACIS system. As shown in ��HFigure 4-1 ACIS PKI Chain of Trust, the TSA Root CA signs (issues/certifies) the public key of ACIS Identity Authority CAs. This TSA Root CA signing of Identity Authority CAs can be viewed as representing the TSA accreditation of the ACIS Identity Authority. Issuance of the subordinate CA certificate in this manner delegates the authority to the ACIS Identity Authority to issue ACIS Certificates (Identity Credentials). It is important to note that once the subordinate CA certificate is signed by TSA, the Identity Authority has complete authority and control over issuance of certificates (and ACIS Identity


February 27, 2008

Page 51

Credentials) by the Identity Authority CA as well as revocation of certificates issued by the Identity Authority.

ACIS PKI Shared Services

TSA ACIS Root CA (off-line)

ACIS Identity Authority(Identity Credential Issuance)

ACIS Identity Authority(PKI Shared Service Provider)

Identity Authority Subordinate CA

ACIS Relying Parties

Subordinate CA Certificates

IDMS Attribute Authority Certificate

Card Management Registration

Authority CertificateACIS Card

ACIS Participant Certificates

ACIS Validation Authority

Validation Authority Certificates

ACIS Certificate Revocation

ACIS Sponsor’s Agent

ACIS Enrollment Agent

ACIS Approval Authority

ACIS Root CA Certificate

ACIS Credential Issuance

ACIS Identity Verification

ACIS Certificate Issuance

ACIS Certificate Status

Subordinate CA Certificate Issuance

Certificate Revocation

List

ACIS AccreditationACIS Agent Certificates

ACIS Adjudication Agent

Digital Signature and Audit


ACIS Access Control

Authorities

ACIS Accreditation

Figure 4-1 ACIS PKI Chain of Trust

4.1.2 ACIS Identity Authority Subordinate CA

The ACIS Identity Authority Subordinate CA issues a variety of certificate types for use in ACIS credentials and within the ACIS Identity Authority ACIS system components. In addition to ACIS Participant Certificates issued on ACIS Identity Credentials, the Identity Authority issues a number of certificate types which are used within the Identity Authority ACIS systems, to support ACIS system security and chain of trust. Certificate types used in ACIS are supported by FPKI Shared Service Provider standard certificate profiles and include:

• ACIS Participant Certificates (mandatory PIV Credential certificates); • ACIS Agent Certificates (optional PIV Credential certificates required by agents to sign

ACIS system transactions and support Logical Access Control to ACIS systems by ACIS Agents);

• ACIS Attribute Authority Certificates (used by the Identity Authority IDMS to sign ACIS Identity Credential data objects, such as the CHUID and biometric templates);


February 27, 2008

Page 52

• ACIS Registration Authority Certificates (used to authenticate certificate issuance and revocation requests to the ACIS Identity Authority CA), and;

• ACIS Validation Authority Certificates, and; • Device Certificates (used to secure device communications for ACIS system devices such

as routers and servers). Note: ACIS Identity Authorities may choose to issue optional PIV compliant ACIS Credential certificates to ACIS participants.

4.2 ACIS Linkage of Revocable Elements The various ACIS entities create and maintain a logical link (identifier) to the information they use to create a new credential under their authority. These various identifiers represent the revocable elements within the ACIS system. A new Identity Credential issuance is always initiated by an ACIS Identity Authority. It collects the information about the ACIS Applicant (reference biometric and biographic enrollment data) and assigns an ACIS Person Identifier to the person’s file in its IDMS. The applicant enrollment information is then sent to the ACIS program CSMS for biometric duplicate check, STA and CHRC. The ACIS CSMS performs a biometric duplicate check (1:n AFIS biometric search) of the applicant reference biometric against the reference biometrics of all ACIS Participants and previously rejected ACIS Applicants. If it is the first time the applicant is seen by the ACIS CSMS (based upon biometric duplicate check), a new ACIS CSMS Index (identifier independent of the Identity Authority) is allocated by the ACIS CSMS. If the person has previously applied for or been issued an ACIS credential (based upon the biometric duplicate check), the ACIS CSMS assigns the existing CSMS Index for that person to the applicant and submits the applicant data for STA and CHRC. Use of the biometric duplicate check assures that the CSMS can detect and associate multiple applications from different ACIS Identity Authorities for the same person, even if the applicant is using a fraudulent identity. The use of the CSMS Index allows the ACIS CSMS to maintain a central linkage to all Identity Authorities who have either issued an ACIS Identity Credential to the same person or who have previously rejected an individual as unsuitable. When the Identity Authority issues a credential to the person, a unique credential identifier is created by the Identity Authority. Later, when an Access Control Authority grants an access privilege to the ACIS Participant, it will create an ACIS privilege identifier (number), unique to the credential and the PACS issuing it. The relationship between these identifiers is represented in ��HFigure 4-2 ACIS Linkage of Revocable Elements and described in the following sections. 4.2.1 ACIS CSMS Index

As described above, the ACIS CSMS Index is allocated each time a new person is presented to the CSMS system. This index is a unique identifier of a given person in the CSMS AFIS database. Because the assignment of the CSMS Index is based upon biometric identification, the ACIS CSMS does not need to rely on Identity Authority assigned person identifiers in order to identify a person who has applied for an ACIS credential through multiple ACIS Identity Authorities. The ACIS CSMS links all ACIS Applicants (current or previous) and ACIS Participants from all ACIS Identity Authorities to the CSMS Index of an individual person. The CSMS index is used to communicate revocation of a person’s ACIS federal suitability either


February 27, 2008

Page 53

from TSA to Identity Authorities or from Identity Authorities to TSA. This linkage allows the ACIS CSMS to:

• Support cascaded revocation of an ACIS Participant by all issuing Identity Authorities if a person is determined to be federally ineligible by any ACIS Identity Authority;

• Support cascaded revocation of an ACIS Participant by all ACIS issuing Identity Authorities if a person is found to be a security threat through TSA STA or perpetual vetting;

• Detect fraudulent applications by ACIS Applicants or ACIS Participants who have previously been rejected as federally unsuitable by any Identity Authority.

• Detect suspicious applications by previous ACIS Participants who have been revoked been by any Identity Authority.

TSA ACISProgram

ACIS CSMS

ACIS CSMS Index

ACIS Access Control Authority

PACS

Privilege Identifier


PACS



PACS


ACIS Identity Authority

IDMS

Person ID

CMS

CHUIDCHUIDCHUID


IDMS

Person ID

CMS

CHUIDCHUIDCHUID


IDMS

Person Identifier

CMS

CHUIDCHUID


PACS


ACIS Certificates

TSA ACISProgram

ACIS PKI

CredentialIdentifier

CRL(CredentialIdentifier)

Figure 4-2 ACIS Linkage of Revocable Elements

The CSMS Index maintained by the CSMS is associated with applicant or participant biometric data, in order to support CSMS AFIS search. The biographic data associated with the person (CSMS Index) is not maintained by the CSMS. The CSMS Index links only the requests of Identity Authorities asking about a given individual to the person’s biometric data. The CSMS does not keep track of the personal identifier allocated by the Identity Authorities to the person.


February 27, 2008

Page 54

This approach allows enhanced security and chain of trust by providing global ACIS revocation mechanisms without privacy impacts associated with centralized identity databases using global identifier attached to biographic data. ACIS Identity Management data is maintained in a distributed fashion under control of each ACIS Identity Authority. While the ACIS CSMS Index is not linked to an individual’s biographic data in the CSMS, the CSMS Index is still highly sensitive in terms of privacy since it points directly to an individual in the ACIS CSMS data base. While the CSMS index is not linked to a person’s biographic data in the CSMS, when combined with Identity Authority person identifiers it does represent a global person identifier within ACIS. It should never be exposed or shared to non-trusted parties and should never be stored in an ACIS Credential. 4.2.2 ACIS Person Identifier

Each Identity Authority manages a unique identifier for each person it has in its IDMS. This identifier is assigned to a given individual the first time the entry is created in the IDMS and is permanent. This identifier is highly sensitive in terms of privacy since it points directly to an individual in the ACIS Identity Authority’s IDMS database. It should never be exposed or shared, even with the ACIS CSMS and should never be stored in an ACIS Credential. The ACIS CSMS index is attached to this ACIS Person Identifier, stored in the Identity Authority’s IDMS database. This association allows the ACIS Identity Authority to know when the suitability of a person changes based upon a message sent by the ACIS CSMS to the ACIS Identity Authority, identifying the Participant based upon the CSMS Index. 4.2.3 ACIS Credential Identifier

When a credential is created for a given person, an ACIS Credential Identifier is allocated by the Identity Authority. This number is unique to the Identity Authority and is stored in the ACIS Identity Credential. It is also stored in the Identity Authority’s IDMS attached to the ACIS Person Identifier. The Credential Identifier should not be re-used and should be as random as possible relative to the person’s identity. It is not acceptable to always use the same credential number allocated to an individual with a badge number incremented each time a new credential is issued to the individual. Following PIV specifications, the ACIS Credential Identifier corresponds to the PIV CHUID and is stored in the ACIS card with no access protection. This identifier can be accessed by many parties and if the number is permanently attached to a given person would then be considered personally identifiable information. In order to protect the user’s privacy, it is important that the credential number is changed completely when a new credential is issued. The detailed structure of the ACIS Credential Identifier is defined in this document in ��HAppendix A - ��HACIS Card Data Model in the sub-section describing the Card Holder Unique Identifier. 4.2.4 PACS Privilege Identifier

When an ACIS Access Control Authority grants an access privilege to an ACIS Participant, an entry is created in the PACS. This entry is uniquely identified in the PACS by a PACS Privilege Identifier. Until recently most PACS allocated an identifier under PACS control without having a requirement for a general unique numbering scheme. The collision between identifiers was prevented by storing a system code (PACS identifier) managed by the PACS manufacturers in the credential. PIV has generalized this mechanism by adding the identifier of the authority


February 27, 2008

Page 55

issuing the credential to the PACS numbering system. This has created the CHUID structure used in ACIS to identify a Participant’s identity credential. Unfortunately, such a number is not random and provides some information about the cardholder (the Identity Authority the user is associated with and the PACS identifier to which the user has access, etc.). ACIS acknowledges the privacy risks of such a numbering scheme. Even though ACIS does not forbid use of such a structure in a PACS, ACIS provides the ACIS Privilege Card-Application with a different mechanism which does not require the credential to broadcast any personal information. When using the ACIS Privilege Card-Application, the PACS Privilege Identifier can be any number chosen by the PACS to identify the privilege granted to the person. This number is stored in the PACS as well as in the ACIS Card, indexed by a PACS identifier (Access Control Authority identifier + PACS system code) and is provided by the card to the PACS which identifies itself using the correct PACS identifier. The ACIS Credential Identifier used during the PACS enrollment is stored in the PACS database, attached to the PACS Privilege Identifier allocated by the PACS. When an ACIS Identity Credential is revoked, the link to the ACIS Credential Identifier is used by the PACS to revoke any Privilege Credentials associated with the ACIS Identity Credential. 4.2.5 Privacy Protection in the ACIS Trust Chain

The identifiers described in the preceding sections provide the linkage of revocable elements within ACIS. Additionally, the use of separate identifiers for the CSMS Index, IDMS Person Identifier, Credential Identifier and Privilege Identifier provide important privacy protection for ACIS Participants. Person Identifiers used in ACIS are by definition, personally identifiable information and should not be disclosed in verification transactions, particularly when the identifier is a global person identifier within a large scheme. Conceptually, this is analogous to the reason banks use a debit card number which is associated with a specific card but is a different number than the cardholder’s bank account number. The use of a CSMS Index, separate from the Identity Authority person identifier, prevents global tracking of an individual based upon the CSMS central database, since the CSMS Index is not present on the ACIS Credential. Because of the nature of the PIV-aligned Cardholder Unique ID (CHUID) as an ACIS credential identifier, the CHUID can be viewed as a personal identifier. PIV specifications recognize this by requiring that a contactless PIV card be maintained in an electromagnetically opaque sleeve when not in use, to prevent reading of the CHUID without cardholder consent. Use of a separate local privilege identifier within ACIS for access control transactions avoids risk of unauthorized disclosure of the CHUID. This ACIS identifier structure is combined with the use of local PACS keys to perform mutual authentication and encrypt biometric templates during transmission between ACIS card and a PACS reader (ACIS Phase III). Together, these structures and cryptographic mechanisms provide strong security and chain of trust while minimizing privacy risks to ACIS Participants.


February 27, 2008

Page 56

5 ACIS Security and Privacy As a secure identification credentialing program, the ACIS system is designed to support and maintain a comprehensive policy for the secure collection, use, exchange and management of all information, including privacy protections for personally identifiable information.

5.1 System Security The fundamental security requirements in the ACIS system focus on the concept of “chain of trust”, and system integrity. The ACIS system must establish and maintain a comprehensive audit trail of its operational processes, including non-repudiation of ACIS Agents and system operators in the performance of system roles, responsibilities and duties.

REQ 5.1-1 All communications between entities shall be established using a certification of origin in order to prevent any injection of erroneous information by un-trusted parties.

REQ 5.1-2 ACIS systems shall monitor and control communications at the external boundary of the information system and at key internal boundaries within the system.

REQ 5.1-3 ACIS systems shall ensure that any connections to the Internet, or other external networks or information systems, occur through controlled interfaces (e.g., proxies, gateways, routers, firewalls, encrypted tunnels).

REQ 5.1-4 ACIS systems shall ensure that the operational failure of the boundary protection mechanism does not result in any unauthorized release of information outside the information system boundary.

REQ 5.1-5 Systems located at designated alternate processing sites shall provide equivalent levels of protection as that of the primary site.

REQ 5.1-6 ACIS systems shall protect the integrity of transmitted information. REQ 5.1-7 ACIS systems shall protect the confidentiality of transmitted information. REQ 5.1-8 ACIS systems shall ensure the availability of transmitted information. REQ 5.1-9 ACIS systems shall protect all Privacy Act and security sensitive information being

processed and/or resident in data repositories from unauthorized access, modification and disclosure.

REQ 5.1-10 ACIS systems shall have a comprehensive asset inventory management system. REQ 5.1-11 ACIS systems shall have a comprehensive configuration management process. REQ 5.1-12 ACIS systems shall have a PKI design and management processes compliant with

Federal laws and standards governing PKI implementation and execution to included key generation, distribution, disposal, protection, and certificate management,

REQ 5.1-13 ACIS systems shall be engineered and sufficiently hardened to be subjected to vulnerability scans, using generally accepted and government approved scanning tools, resulting in no adverse findings and identifiable vulnerabilities.

REQ 5.1-14 ACIS systems shall be security engineered and hardened to prevent, detect, react and recover from malicious attacks or inadvertent user actions.

REQ 5.1-15 ACIS systems shall have host-based intrusion detection capabilities. REQ 5.1-16 ACIS systems shall have network-based intrusion detection capabilities. REQ 5.1-17 ACIS systems shall have the capability to collect intrusion detection data for analysis and

forensic activities. REQ 5.1-18 ACIS systems shall provide the ability to centrally manage the selection of events to be

audited by individual components of the system. REQ 5.1-19 ACIS systems audit trail should include (1) Identity of each person, device, and

processes’ successful and unsuccessful access attempts (2) Time, date, duration of


February 27, 2008

Page 57

access and logoff (3) Activities performed by administrators (4) All changes to security-relevant settings, e.g. access rights( 5) Sufficient detail to facilitate reconstruction of events proceeding a system compromise.

REQ 5.1-20 ACIS systems shall provide an audit trail capability to track the actions of all users identified by logon ID.

REQ 5.1-21 ACIS systems shall audit the success and failure of events and objects with time stamps generated by synchronized system clocks.

REQ 5.1-22 ACIS systems shall provide an audit trail capability to monitor the system access of all users identified by logon ID.

REQ 5.1-23 ACIS systems shall provide the ability to monitor, manage, and review audit records within independent system components.

REQ 5.1-24 ACIS systems shall provide sufficient storage area to collect audit trail information such that audit failure and/or storage overload does not occur.

REQ 5.1-25 ACIS systems shall protect audit trails from unauthorized access and deletion.

5.2 Privacy All ACIS systems must enable and support the need for personal privacy protection. The critical element to accomplishing this is the careful management of personally identifiable information collected from, and ascribed to, the ACIS population as applicants and participants. The use of biometric identifiers in the security design of the ACIS program, introduces a personal data handling challenges that are not unique to ACIS, and which can be managed in a similar fashion, relative to privacy, to that seen in other federal credentialing programs like PIV and TWIC.

REQ 5.2-1 Identity Authorities shall establish a written privacy policy to govern the data collected in connection with the ACIS program and shall make available this policy to all ACIS Applicants.

REQ 5.2-2 Identity Authorities shall inform applicants they can obtain a copy of the Federal Privacy Act at the time of enrollment.

REQ 5.2-3 No personally identifiable information shall be released to a requestor which has not been successfully authenticated as part of the ACIS accredited entities.

REQ 5.2-4 Identity Authorities shall not disclose or use any biographic and/or biometric information collected for the ACIS program other than for ACIS purposes. Disclosure of data will be governed by the government’s ACIS Privacy Impact Assessment (PIA).

REQ 5.2-5 No personally identifiable information shall be released by the ACIS card without user consent or knowledge.

REQ 5.2-6 ACIS Participants shall have access to redress to any personal information stored or used by any ACIS system or service.

REQ 5.2-7 ACIS Participants shall have disclosure about the personally identifiable information stored or used by any ACIS system or service.

REQ 5.2-8 Any personally identifiable information collected by the ACIS system during enrolment or as part of the ACIS process itself shall be protected against intentional or accidental disclosure to unrelated parties.

REQ 5.2-9 The system shall protect all Privacy Act and security sensitive information being processed and/or resident in data repositories from unauthorized access, modification and disclosure.


February 27, 2008

Page 58

5.3 Authentication Enabling the capability for confident electronic authentication within, and between, the ACIS system and the ACIS operatives, fundamentally supports the ACIS system security requirements. These requirements lay the foundation for ACIS system security internally, as well as, the secure use of the ACIS credential externally.

REQ 5.3-1 Entities exchanging information shall use a mutual authentication protocol to establish communication.

REQ 5.3-2 Entities receiving information shall be able to authenticate the sender’s message or data as generated by an ACIS trusted entity.

REQ 5.3-3 User Authentication shall use a PIN or a biometric technique where the reference information is known by the challenging system (e.g. PACS).

REQ 5.3-4 No personally identifiable information shall be transmitted by any entities, elements or devices (including smart cards) to an un-authenticated party except when the cardholder has provided its explicit consent to its card.

REQ 5.3-5 The system must store all passwords, algorithms, keys, certificates, codes, or other schemes that are used by the system for authentication purposes in a manner that prevents unauthorized individuals from gaining access to them.

REQ 5.3-6 The system shall provide, to a user during an attempted authentication, feedback that does not weaken the strength of the authentication mechanism.

REQ 5.3-7 The system shall obscure the feedback of authentication information during the authentication process, such as displaying asterisks when a user types a password.

5.4 Data Integrity Data integrity enables and supports the concept of a secure “chain of trust” throughout the ACIS system.

REQ 5.4-1 Information exchanged between entities and devices shall use data integrity techniques (e.g. digests) allowing to verify the information has not been accidentally or intentionally altered after being created.

REQ 5.4-2 Data Integrity may be combined with certification of data origin (e.g. signed digest).

5.5 Data Confidentiality Because the ACIS credential will store and carry personally identifiable information, the confidentiality of such data must be considered and protected.

REQ 5.5-1 Personally identifiable information shall be stored at rest with appropriate access protections preventing any accidental use by or disclosure to un-authorized parties. This shall consist in access restrictions to secure data storage (such as smart cards) and of encrypting the information on transportable unprotected media (tapes, USB tokens, hard drives, etc.).

REQ 5.5-2 Personally identifiable information exchanged between a card and a terminal shall be reasonably protected against man in the middle attacks. This requires any contactless transmission to be encrypted when exchanged.

5.6 ACIS Key Management REQ 5.6-1 ACIS components shall comply with NIST SP800-57 for key management.


February 27, 2008

Page 59

6 ACIS Card The issued ACIS Card is the visible feature of the ACIS Program. The main objective of the ACIS credential is to confidently assure the cardholder is legitimate and is a trustworthy person working for a given employer (sponsor). During the three phases of implementation the ACIS credential will have two topographies, contain an identity credential, and in the last phase, an application to enable the use of local access control privilege.

Note: As SIDA topography is not standardized across airports, employees having SIDA access privileges at multiple airports may have to carry multiple badges even in ACIS Phase III under existing SIDA Challenge rules.

6.1 Applications in the ACIS Card The ACIS Identity Credential is based on the PIV credential model, so it follows that the existing products qualified for PIV should be usable with minor modifications for the ACIS identity credential. The following sections assume a good knowledge of the PIV specifications. In order to provide an understanding of how ACIS and PIV differ, this specification presents only the differences between the ACIS Identity Credential and the PIV Credential. In order to capitalize as much as possible on the existing PIV products, the ACIS specification does not try to correct or alter the PIV specification proprietary interpretations of the ISO/IEC 7816 standard. It even reuses the same names as PIV when the data objects are identical in order to minimize the changes in the card application as well as in the client applications. The ACIS card application identifier is different than PIV and is under the control of TSA. It uses a structure very similar to PIV and indicates the version and characteristics of the current application in the ACIS card. The ACIS card application is not a closed name space and provides an issuer name space within the ACIS name space for issuer specific data objects not covered by the requirements for interoperability. This allows ACIS issuers to create additional data objects on the card, without developing a new card application. The ACIS card application will be developed in two different versions. The first version, using only a contact interface, supports the identity information aspect of the ACIS Identity Credential and is detailed in this document. A second version, supporting secure contactless communication will enable the functionality for registering and using the ACIS card with multiple PACS in access control functions (access privilege functions). The following requirements are taken into account in the detailed card specifications provided in the appendices. They list the requirements for security, privacy and behavior essential to the integrity of the credential used in the ACIS system.

ACIS Card Application Requirements REQ 6.1-1 The ACIS card shall not allow any personally identifiable information to be released over

the contactless interface unless a mutual authentication has taken place and a cryptographic session key has been established, thus preventing such information from being transferred by the card in clear text.


February 27, 2008

Page 60

REQ 6.1-2 The ACIS card shall not allow any personally identifiable information to be released in clear text over any interface without explicit user consent or knowledge as long as the card is under the control of its legitimate user.

REQ 6.1-3 The ACIS card shall use the presentation of a correct PIN as indication of user consent. REQ 6.1-4 The ACIS card shall support biometric user authentication by the terminal and provide

user biometric information in ciphered format to an authenticated terminal, or in clear text after the user has consented to release it.

Note: In future releases the ACIS Card may support direct user authentication (e.g. Match-on-Card) when interoperability and performance (accuracy) issues have been addressed.

REQ 6.1-5 The ACIS card shall provide fingerprint templates as defined in SP800-76 as the mandatory interoperable biometric (Reference Biometric).

REQ 6.1-6 The legitimate user signed digital facial image formatted according to SP800-73-2 shall be present in the card, protected by user consent (card PIN) and available on the contact interface.

Note: This facial image is intended for human verification only but provides a digital signature to certify its authenticity.

REQ 6.1-7 In addition to the Reference Biometric, the ACIS card shall allow another optional user biometric authentication technology (Operational Biometric) to be available on the card. In the issuer card specification, more than one alternate biometric technology to choose from may be specified. The choice of the alternate biometric is under the control of the card issuer (Identity Credential Issuer).

Note: In future releases the ACIS card may support direct user authentication (e.g. Match-on-Card) when interoperability issues have been addressed.

REQ 6.1-8 The ACIS card shall allow access control authorities willing to do so to register in the card an access control privilege granted to the subject for the PACS they manage.

REQ 6.1-9 The registration of a given access control privilege or an operational biometric in an ACIS card shall be performed using the contact interface of the card and under a secure exchange authorized by the ID credential authority managing the card (card issuer).

Note: This may be done on-line or off-line mode (secure e-mail model).

REQ 6.1-10 The ACIS card shall allow PACS registered in the credential to use the ACIS card as an access control token.

REQ 6.1-11 The ACIS card used in access control mode shall allow each PACS to identify the card using its own privilege numbering scheme as well as a mutual authentication scheme.

REQ 6.1-12 The ACIS card shall offer at least one common interoperable mutual authentication protocol for all PACS allowing ACIS Access Control Authorities to choose their own key.

REQ 6.1-13 All command and responses exchanged between the ACIS card and the terminal it is connected to shall comply with the ISO/IEC 7816 series and use interoperable options (no proprietary mode allowed).

Note: It is expected the command set used to be as much as possible compliant with the PIV SP800-73 end-point specification.

REQ 6.1-14 The ACIS Data Objects not already defined in other application space (e.g. PIV or ISO/IEC 7816) shall be defined within the ACIS application domain space (the ACIS


February 27, 2008

Page 61

AID) using ASN.1 BER-TLV encoded tags with the proprietary ASN.1 (application specific) class.

REQ 6.1-15 The ACIS card application shall not prevent, if chosen by the card issuer, other applications to be loaded in the card under the control of the ACIS Identity Authority.

6.1.2 ACIS Identity Card-Application

As described in Section 2.5.1 of this document, during ACIS Phase I, all the ACIS credentials issued by ACIS Aircraft Operators and ACIS Airport Operators will have the ACIS ICC chip containing the ACIS Identity Credential. This credential consists of a contact ICC chip containing a card-application (as defined in the IEC/ISO 7816 standards). The ACIS identity card-application is very similar to the PIV implementation described in SP 800-73.

ACIS Identity Card-Application Requirements REQ 6.1-16 The ACIS Identity Card-Application shall provide, after user consent, basic identity

information (e.g. name, employer, facial image, credential number, etc.) on its contact interface about its legitimate bearer.

REQ 6.1-17 The ACIS Identity Card-Application shall provide digital signatures on all identity data structures (either individually or a whole) created by an ACIS Identity Credential Issuer.

REQ 6.1-18 The ACIS Identity Card-Application shall not allow clear text biometric information to be available without explicit user consent or knowledge when the user is in control of the card.

6.1.3 ACIS Privilege Card-Application

The privilege card application is introduced in ACIS Phase III and can be accessed through both the contact and contactless interface of the ICC chip of the ACIS Card. A brief overview of the functionality of this application can be found in Appendix C - ACIS Privilege Application. The detailed specifications of this application are not available in phase I and are to be developed during ACIS Phase II or at the beginning of ACIS Phase III.

ACIS Privilege Card-Application Requirements REQ 6.1-19 Each new access control privilege shall be registered in the ACIS card-application as a

given PACS entry identifying the new PACS registered. REQ 6.1-20 Privilege registration shall include the privilege identifier under which the ACIS card is

registered in a given PACS along with the security handshake required for this PACS to communicate with the ACIS card.

REQ 6.1-21 Each PACS registered in a given ACIS card shall be able to identify itself to the ACIS card allowing the card to release the identifier under which the ACIS card has been registered in the given PACS.

REQ 6.1-22 PACS administrators as well as legitimate ACIS card holders shall be able to remove their PACS identifier from a given ACIS card.

6.2 ACIS Physical Card During the three phases of ACIS deployment two types of physical badges will be issued. One type of badge is to be issued by ACIS Airport Operators and the other type is issued by ACIS Aircraft Operators. The badge topography requirements for these two types of badges are


February 27, 2008

Page 62

generally described in the following sections. Both ACIS badge types will have an ACIS Identity Credential, and as such will comply with international standards related to contact ICC physical specifications.

ACIS Physical Card Requirements REQ 6.2-1 ACIS badges shall comply with the physical and electrical characteristics described in

this document in Appendix E, ��HACIS Physical and Electrical Card Characteristics.

6.3 ACIS Airport Operator Issued Badge Topography This ACIS Airport Operator issued badge topography is under the control of Airport Operators and is not determined by the ACIS Program. This badge’s design aspect is under the sole control of the Airport Operator and shall accommodate the federal regulations for a visual SIDA challenge. ACIS requires that the ACIS ICC credential (contact chip) must be accommodated in the Airport Operator’s badge design. This may require airports to modify their existing badge design and have the card body comply with the Integrated Circuit Card specifications defined in ISO/IEC 7816 (parts 1, 2 and 3).

Note: The following lists the existing requirements for the airport issued badge and is extracted from Title 49, Code of Federal Regulations (CFR), Chapter XII, Part 1542.211: The personnel identification system must include a personnel identification media that— (i) Convey a full-face image, full name, employer, and identification number of the individual to whom the identification medium is issued; (ii) Indicate clearly the scope of the individual’s access and movement privileges; (iii) Indicate clearly an expiration date; and (iv) Are of sufficient size and appearance as to be readily observable for challenge purposes.

6.4 ACIS Aircraft Operator Issued Badge Topography The ACIS Aircraft Operator issued badges do not have a regulated requirement for their topography, and are not tied to a specific airport. There is a need to have an interoperable ACIS topography between all Aircraft Operators in order to provide a uniform standard that can be recognized by Airport Operators. The ACIS Aircraft Operator issued badge topography is specified by the ACIS Program. The Aircraft Operator issued badge topography is detailed in this document in Appendix D – ACIS Visual Card Topography and is based on the PIV topography. In order to easily distinguish this badge topography from any ACIS Airport Operator issued badge used for SIDA challenge, a visible zone is reserved on the badge (zone 15f) showing clearly the SIDA access control section is not present on the topography of such badge. The detail and specific placement of the various zones are described in Appendix D of this document. This section presents only the high level requirements and refers to the appendixes for the detailed information printed on the ACIS badge. All the information printed on the ACIS badge is also available in electronic form in the chip. This data can be verified electronically for integrity and authenticity using the digital certificate of the issuing Identity Authority.


February 27, 2008

Page 63

6.4.1 Mandatory Items on the ACIS Aircraft Operator Card

The various mandatory fields on the ACIS identity card are used to verify the identity claim of the card holder by a visual challenge. As the coding of the SIDA access level is defined by each airport, and as typically Aircraft Operator badges have to be used at multiple airports, the SIDA access level is not coded on such badge and the zone 15f indicates clearly the badge is not an Airport Operator issued SIDA badge. This topography is designed to enable a common (interoperable) identity badge style for all ACIS Aircraft Operator cardholders. The ACIS topography should be understood to provide visible and electronic verifiable identity information rather than a local access privilege credential required for physical access.

ACIS Aircraft Operator Mandatory Card Topography Requirements REQ 6.4-1 The Aircraft Operator issued badge shall incorporate mandatory topographic elements

as defined in Appendix D. Optional items are standardized in the ACIS topography and can be used for interoperability purposes, but are not required. The choice of opting for their presence is under the control of the issuing Identity Authority but their definition is ruled by this specification. Because the printing space available on a card is limited, not all optional features can be present on a given card. When some zones are assigned to the same location in the topography, their presence may be exclusive or their size may have to be modified to fit in the allocated area.

ACIS Aircraft Operator Optional Card Topography Requirements REQ 6.4-2 When the Aircraft Operator chooses to incorporate optional topographic elements on the

front or the back of the badge, they shall be placed and used as defined in Appendix D.

6.4.2 Topography Considerations for ACIS Airport Operator Local Badges

At the end of ACIS Phase I, the local badges issued by ACIS Airport Operators will contain an added ACIS identity credential (contact ICC). The information written in the ACIS ICC added to such a badge shall be structured in accordance to this specification but the impact on the topography of the local badge is limited to the physical and electrical constraints created by adding a smart card contact ICC into a badge. General indications are available about such constraints in the FIPS 201 specification. This specification does not propose any additional constraints or requirement for such an addition. It is believed that most issuing airports will already have a relationship with a given card manufacturer and a given card printer/personalization equipment manufacturer. Therefore, the constraints of moving from their existing badge (with or without contactless or proximity technology) to a contact smart card based badge may be simplified by direct discussions with these manufacturers.


February 27, 2008

Page 64

7 ACIS Phase I Use Cases ACIS Phase I use cases comprise use cases to sponsor and determine suitability of ACIS Applicants to become ACIS Participants or ACIS Agents and to issue, use, maintain and revoke ACIS Identity Credentials within Phase I of the ACIS Program. Phase I use case categories include:

• Sponsor Approval Use Cases - Approval process used to establish employers as ACIS Sponsors;

• Identity Credential Issuance Use Cases - Sponsor and enroll ACIS applicants to become ACIS Participants and ACIS Agents. Determine applicant suitability and approve, issue and produce ACIS Identity Credentials;

• Identity Credential Maintenance Use Cases - Maintain ACIS Identity Credentials including PIN change and PIN unblock;

• Identity Credential Re-issuance Use Cases – Re-issue ACIS Credentials as required due to loss, theft damage or changes to Participant information;

• Identity Credential Revocation Use Cases – Revoke credentials due to termination of ACIS participation or revoke ACIS participation due to changes in Participant suitability.

Privilege Credential

Registration Use Cases


UsageUse Cases

Identity Credential

UsageUse Cases

Digital Signature

Subordinate Use Cases

Identity Verification Subordinate Use Cases

Identity Credential Issuance

Use Cases

Sponsor Approval

Use Cases

Identity Credential

Maintenance Use Cases

Identity Credential

Re-issuance Use Cases

Identity Credential Revocation Use Cases

ACIS Phase I Use Cases

ACIS Phase III Use Cases

ACIS Phase II Use Cases

Figure 7-1 ACIS Phase I Use Cases Categories

ACIS Phase I use cases assume that Identity Authority roles have been established through implementation of Enrollment System, Identity Adjudication System and Identity Credential


February 27, 2008

Page 65

Issuance System using ACIS compliant elements and that the ACIS Identity Authority has been accredited by TSA.


February 27, 2008

Page 66

7.1 Sponsor Approval Use Cases Sponsor Approval Use Cases comprise use cases to approve and to establish employers as ACIS Sponsors. Sponsor Approval use cases are illustrated in the following figure and include:

• Sponsor Enrollment; • Agent Enrollment; • Agent Vetting and Adjudication, and; • Optional Certificate Issuance.

ACISAdjudication

Agent

Agent Enrollment

Sponsor Enrollment

Applicant Enrollment Agent Vetting


Issuer Security

Coordinator

Sponsor suitability determination Agent candidates

sponsored as ACIS applicants

ACIS applicant vetting (sponsor’s agent

candidate)

ACISApplicant

ACIS credential issuance

Agent suitability determination

Optional Certificate Issuance

Aviation Employer

Aviation Employer

ACIS Sponsor

Sponsor enrollment request

Agent certificate issuanceACIS

Participant

ACIS Participant

ACIS Sponsor’s

Agent

Issuer Security

Coordinator

Sponsor approved

Figure 7-2 Sponsor Approval High-Level Flow

7.1.1 Sponsor Enrollment

Description: Sponsor enrollment is the enrollment of an aviation employer as an ACIS Sponsor. An ACIS Sponsor has employees that require unescorted access to Airport facilities and who can authorize those employees to enroll for an ACIS card.


February 27, 2008

Page 67

Initial Conditions: Employer is not enrolled as an ACIS Sponsor. Employee is not an ACIS Participant or an ACIS Sponsor’s Agent.

End Conditions: ACIS Sponsor is enrolled and authorized by the ACIS Identity Authority. ACIS Sponsor’s Agent(s) is enrolled and authorized to act on behalf of the Sponsor to perform the required ACIS Enrollment processes for the Sponsor’s employees.

Actors Involved: Aviation Employer ACIS Sponsor Issuer Security Coordinator ACIS IDMS ACIS Applicant ACIS Participant ACIS Sponsor’s Agent

Use Case Assumptions: None.

Main Flow: Sponsor Enrollment 1. The Aviation Employer formally requests ACIS Sponsor status with enrollment through

an ACIS Issuer Security Coordinator to become an ACIS sponsor. 2. The Aviation Employer provides the Issuer Security Coordinator with identifying

employer information including company name, company address, company contact information, reason for sponsorship request, company Employer Identification Number (EIN) and company Data Universal Numbering System (DUNS) Number.

3. The Aviation Employer submits Sponsor’s Agent candidate(s) applicant information with associated justification for ACIS Agent status to the ACIS Issuer Security Coordinator to enroll Applicant(s) as Sponsor’s Agent(s).

4. The Issuer Security Coordinator or designate initiates vetting of the Aviation Employer as required by the ACIS Compliance Authority. If the Aviation Employer is found to be unsuitable, flow passes to Alternate Flow: Sponsor Rejected.

5. The Issuer Security Coordinator sponsors the Sponsor’s Agent candidate(s) as ACIS Applicants. Flow passes to Main Flow: Applicant Enrollment.

6. Upon rejection of a Sponsor’s Agent candidate as unsuitable to perform Sponsor’s Agent duties, the Issuer Security Coordinator notifies the Aviation Employer and the Agent candidate of the rejection. (note that the ACIS Applicant may be still be suitable as an ACIS Participant)

7. If all Sponsor’s Agent candidates are rejected as ACIS Applicants, flow passes to Alternate Flow: Sponsor Rejected.


February 27, 2008

Page 68

8. Upon successful determination of suitability of one or more Sponsor’s Agent candidate (s) as ACIS Participants, the IDMS initiates enrollment of candidates as ACIS Agents. Flow passes to Main Flow: Agent Enrollment.

9. The Issuer Security Coordinator digitally signs an authorization of the Aviation Employer as an ACIS Sponsor.

10. The Issuer Security Coordinator creates an ACIS Sponsor record in the IDMS which stores the associated approved Sponsor’s Agent information.

11. The IDMS creates an audit record of the accepted Issuer Security Coordinator authorization of the ACIS Sponsor.

12. The Identity Authority notifies the ACIS Sponsor and approved Sponsor’s Agents of successful completion of sponsor and agent enrollment and the use case ends.

Alternate Flow: Sponsor Rejected 13. The IDMS creates an audit record of the Issuer Security Coordinator rejection of the

ACIS Sponsor. 14. The Issuer Security Coordinator notifies the ACIS Sponsor of rejection of the sponsor

enrollment and the use case ends.

7.1.2 Agent Enrollment

Description: The Agent Enrollment use case provides for the additional vetting of an ACIS Participant required by the ACIS Compliance Authority and enrolls the ACIS Participant as an ACIS Agent. Supplemental vetting of the ACIS Participant (e.g. credit check) to determine suitability to act as an ACIS Agent is performed as required by the ACIS Compliance Authority.

Initial Conditions: An ACIS Participant has been sponsored for processing to become and ACIS Agent.

End Conditions: Main Flow: ACIS Participant is enrolled as an ACIS Agent. Alternate Flow: ACIS Participant is rejected as an ACIS Agent.

Actors Involved: ACIS Participant ACIS Agent Issuer Security Coordinator Identity Management System (IDMS) Card Management System (CMS) CMS Activation Station Identity Adjudication System Identity Adjudication Agent


February 27, 2008

Page 69

Extended Vetting Services

Use Case Assumptions: The ACIS Participant has provided contact information (e.g. e-mail account, phone number to receive notifications.

Main Flow: ACIS Agent Enrollment 1. The ACIS Participant is sponsored as an Agent candidate and provides consent (wet

signature on a form) to become an ACIS Agent specifying the Sponsor and type of ACIS Agent (e.g. Enrollment Agent, Sponsor’s Agent).

2. The Issuer Security Coordinator receives Participant consent and submits an Agent Enrollment request to the IDMS.

3. The IDMS updates the Participant record to indicate initiation of agent enrollment. 4. The IDMS determines whether the Participant has previously been vetted to act as an

ACIS Agent. 5. If the Participant does not have a current vetting status to act as an ACIS Agent, flow

passes to Main Flow: Agent Vetting and Adjudication.

Main Flow: ACIS Agent Certificate Issuance 6. The Participant has been successfully vetted to act as an ACIS Agent. The IDMS

initiates a request to the CMS to issue ACIS Agent Certificates to the Participant. 7. The IDMS schedules an appointment for ACIS Agent training and notifies the

Participant. 8. The Participant completes agent training and the IDMS updates the Participant record

to indicate successful completion of agent training. 9. The Participant presents his/her ACIS card to a CMS Activation Station. 10. The CMS issues Agent Certificates to the Participant’s ACIS card by initiating

Alternate Flow: Optional ACIS Certificate Issuance. 11. The CMS notifies the IDMS that Agent Certificates have been issued to the

Participant. 12. The IDMS updates the participant record to indicate completion of Agent Enrollment. 13. The IDMS notifies the Issuer Security Coordinator of completion of ACIS Agent

Enrollment and the use case ends.

Alternate Flow: ACIS Agent Vetting 14. The IDMS initiates Agent vetting by sending an Agent vetting request to the Identity

Adjudication System. 15. The Identity Adjudication System requests vetting information from Extended Vetting

Services. 16. The Identity Adjudication System compares vetting data to Agent suitability

requirements. 17. If Agent suitability requirements are met, flow passes to Main Flow: Participant

Accepted as ACIS Agent.


February 27, 2008

Page 70

18. The Identity Adjudication System notifies an ACIS Adjudication Agent of the pending case requiring adjudication.

19. The Adjudication agent inspects the vetting information and adjudicates suitability of the Participant to act as an ACIS agent.

20. If the Participant is determined to be unsuitable, Flow passes to Alternate Flow: Participant Unsuitable as ACIS Agent.

Main Flow: Participant Accepted as ACIS Agent. 21. The Identity Adjudication System digitally signs the Agent adjudication status

indicating that the Participant is suitable to act as an ACIS Agent. 22. The Identity Adjudication System sends Agent adjudication status to the IDMS

indicating that the Participant is suitable to act as an ACIS Agent. Flow passes to Main Flow: ACIS Agent Certificate Issuance.

Alternate Flow: Participant Rejected as ACIS Agent 23. The Identity Adjudication Agent digitally signs the Agent adjudication status indicating

that the Participant is not suitable to act as an ACIS Agent. Flow passes to Main Flow: ACIS Digital Signature.

24. The Identity Adjudication System sends Agent adjudication status to the IDMS indicating that the Participant is not suitable to act as an ACIS Agent.

25. The IDMS updates the participant record to indicate rejection of the Participant as an ACIS Agent.

26. The IDMS notifies the Issuer Security Coordinator of rejection of the Participant as an ACIS Agent and the use case ends.

7.1.3 Agent Vetting and Adjudication

Description: The Agent Vetting and Adjudication use case performs Agent suitability determination based upon requirements established by the ACIS Compliance Authority.

Initial Conditions: The IDMS has initiated Agent vetting by sending an Agent vetting request to the Identity Adjudication System.

End Conditions: Main Flow: Participant has been determined to be suitable to act as an ACIS Agent. Alternate Flow: Participant rejected as an ACIS Agent.

Actors Involved: Identity Adjudication System Adjudication Agent Extended Vetting Services


February 27, 2008

Page 71

Use Case Assumptions: None

Main Flow: Agent Vetting and Adjudication 1. The Identity Adjudication System requests vetting information from Extended Vetting

Services. 2. The Identity Adjudication System compares vetting data to Agent suitability

requirements. 3. If Agent suitability requirements are met, flow passes to Main Flow: Participant

Accepted as ACIS Agent. 4. The Identity Adjudication System notifies an ACIS Adjudication Agent of the pending

case requiring adjudication. 5. The Adjudication agent inspects the vetting information and adjudicates suitability of

the Participant to act as an ACIS agent. 6. If the Participant is determined to be unsuitable, Flow passes to Alternate Flow:

Participant Unsuitable as ACIS Agent.

Alternate Flow: Participant Accepted as ACIS Agent 7. The Identity Adjudication System digitally signs the Agent adjudication status

indicating that the Participant is suitable to act as an ACIS Agent. 8. The Identity Adjudication System sends Agent adjudication status to the IDMS

indicating that the Participant is suitable to act as an ACIS Agent. Flow passes to the initiating use case.

Alternate Flow: Participant Rejected as ACIS Agent 9. The Identity Adjudication Agent digitally signs the Agent adjudication status indicating

that the Participant is not suitable to act as an ACIS Agent. Flow passes to Main Flow: ACIS Digital Signature.

10. The Identity Adjudication System sends Agent adjudication status to the IDMS indicating that the Participant is not suitable to act as an ACIS Agent. Flow passes to the initiating use case.

7.1.4 Optional Certificate Issuance

Description: The Optional Certificate Issuance use case issues signing and encryption keys and certificates to an ACIS card as required for ACIS Agents and optionally required for ACIS Participants by the Identity Credential Issuer.

Initial Conditions: ACIS Card has been personalized with mandatory ACIS certificates.

End Conditions: Main Flow: An ACIS card is personalized with optional ACIS Certificates.


February 27, 2008

Page 72

Actors Involved: Identity Authority CMS Identity Authority CA ACIS Card

Use Case Assumptions: The ACIS credential is presented into a card reader accessible to the ACIS CMS.

Main Flow: Optional ACIS Certificate Issuance 1. The CMS authenticates to the ACIS Card using the Identity Credential Issuer Key and

establishes a secure channel with the ACIS card (message authentication with encryption) using dynamic session keys.

2. The CMS sends a request to the ACIS Card to generate a Digital Signature key pair. 3. The ACIS Card generates the requested key pair and returns the public component to

the CMS. 4. The CMS request proof of possession of the private key from the ACIS card. 5. The Card returns proof of possession (signed data) to the CMS. 6. The CMS constructs a certificate request based upon the generated public key and

proof of possession. 7. If the Key Management Key is not configured by the Identity Credential Issuer, flow

passes to Alternate Flow: Optional Certificate Request. 8. The CMS generates a Key Management key pair and constructs a certificate request

based upon the generated public key. 9. The CMS generates proof of possession of the private keys and include proof in the

certificate request. 10. The CMS encrypts the private key and submits the wrapped key to the Identity

Authority CA for key escrow. 11. The use case ends and flow returns to the initiating use case.

Alternate Flow: Optional Certificate Request 12. The CMS authenticates to the Identity Authority CA using a Registration Authority

certificate and establishes a secure session for transmission of certificate issuance requests.

13. The CMS requests issuance of the configured optional certificates by the Identity Authority CA.

14. The Identity Authority CA verifies proof of possession of the private keys for the requested certificates.

15. The Identity Authority CA constructs and signs the requested certificates and returns them to the CMS.

16. The CMS writes the requested certificates and corresponding Key Management private key (if configured) to the ACIS card using the secure channel.

17. The CMS closes the secure channel to the card. 18. The use case ends and flow returns to the initiating use case.


February 27, 2008

Page 73

7.2 Identity Credential Issuance Use Cases Identity Credential Issuance Use Cases include use cases to sponsor and enroll ACIS applicants to become ACIS Participants and ACIS Agents. Identity Credential Issuance also includes use cases to determine applicant suitability, approve, issue and produce ACIS Identity Credentials. Identity Credential Issuance use cases are illustrated in the following figure and include:

• Applicant Sponsorship; • Applicant Enrollment; • Federal Suitability Vetting; • Extended Suitability Vetting; • Identity Credential Issuance; • Card Production and Personalization, and; • Card Activation.

ACISAdjudication

Agent

ACISActivation

Agent

Applicant Enrollment

Applicant Sponsorship

Federal Suitability

Vetting

Extended Suitability

Vetting


Card Production and Personalization

Card Activation

ACIS Enrollment

Agent

ACIS Sponsor’s

Agent

ACISApplicant

ACISParticipant

Biographic data submission

Enrollment authorization

Identity document verification

Biometric duplicate check

Document and biometric capture

ACISApplicant

STA and CHRC request

Local vetting request

Applicant suitability determination

Identity Credential Use

Credential issuance authorization

Local PACS card initialization

ACISApproval Authority

Identity credential data object creation

Card topography personalization

ACIS certificate issuance ACIS chip

personalization

Biometric template generation

Biometric identity verification

PIN selection and card unlock

Figure 7-3 ACIS Identity Credential Issuance High-Level Flow

7.2.1 Applicant Sponsorship

Description: The Applicant Sponsorship use case sponsors an applicant for participation in ACIS.


February 27, 2008

Page 74

Initial Conditions: An ACIS Applicant employed by an approved ACIS Sponsor has justification to be issued an ACIS credential.

End Conditions: Main Flow: Sponsored applicant proceeds to ACIS Applicant Enrollment Alternate Flow: Applicant sponsorship is rejected.

Actors Involved: ACIS Applicant ACIS Sponsor’s Agent ACIS IDMS

Use Case Assumptions: Sponsor has an e-mail account and access to a computer on the Internet. Applicant has access to a computer on the Internet.

Main Flow: Applicant Sponsorship 1. The Applicant provides consent (wet signature on a form) to the Sponsor (Applicant's

employer) to initiate the ACIS application process. 2. The Sponsor's Agent authorizes ACIS Enrollment by providing digitally signed

information about the Applicant (Name, Employer ID, Employee ID, Job Title and SSN) with justification for ACIS participation to the IDMS.

3. The IDMS receives the enrollment authorization from the Sponsor's Agent and authenticates the signature of the Sponsor. Flow passes to ACIS Signature Verification to verify the signature.

4. If the signature verification fails, flow passes to Alternate Flow: Reject Applicant Sponsorship.

5. The IDMS verifies that the requesting Sponsor's Agent is an authorized Sponsor's Agent and verifies the completeness of the enrollment authorization.

6. If the Sponsor’s Agent is not authorized or the enrollment authorization is incomplete, flow passes to Alternate Flow: Reject Applicant Sponsorship.

7. The IDMS generates a unique IDMS Applicant Identifier and stores the IDMS Applicant Identifier and sponsorship authorization in the IDMS.

8. The IDMS generates an Enrollment Reservation Number and password for the Applicant to be used to complete an on-line ACIS application and provides that information to the Applicant’s Sponsor’s Agent.

9. The IDMS creates an audit record of the successful enrollment authorization. 10. The Sponsor’s Agent provides the Enrollment Reservation Number and Password to

the ACIS Applicant. 11. The Applicant uses the Enrollment Reservation Number and password to access an

IDMS on-line application and enters the required applicant biographic data. 12. The Applicant completes the application and submits it to the IDMS.


February 27, 2008

Page 75

13. The IDMS verifies that required fields are present in the application and stores the application under the previously generated IDMS Applicant Identifier.

14. The IDMS provides the Enrollment Reservation Number to the Applicant, along with available enrollment schedule, instructions and location for enrollment.

15. The ACIS Applicant selects a date and time for enrollment and submits to the IDMS. 16. The IDMS confirms the enrollment appointment to the Applicant. 17. The IDMS creates an audit record of the successful enrollment authorization. 18. Flow passes to Applicant Enrollment Use Case. 19. Applicant Sponsorship Use Case Ends and flow passes to Main Flow: Applicant

Enrollment.

Alternate Flow: Reject Applicant Sponsorship 20. The IDMS creates an audit record of the failed enrollment authorization. 21. The IDMS notifies the requesting Sponsor’s Agent of rejection of the Applicant

sponsorship request and the use case ends.

7.2.2 Applicant Enrollment

Description: The Applicant Enrollment use case gathers applicant enrolment information and provides identity proofing by the ACIS Enrollment Agent.

Initial Conditions: An ACIS Applicant has been successfully sponsored by an ACIS Sponsor.

End Conditions: Main Flow: Sponsored ACIS Applicant is successfully enrolled.

Actors Involved: ACIS Applicant ACIS Enrollment Agent ACIS Enrollment System ACIS IDMS

Use Case Assumptions: Biometric enrollment typically involves sample acquisition, segmentation and feature extraction, quality checks (which may reject the sample/features as being unsuitable for creating a template, and require acquisition of further samples, template creation, test verification to ensure that the resulting enrollment is usable, and should the initial enrollment be deemed unsatisfactory, repeated biometric enrollment attempts may be allowed (depending on enrollment policy).


February 27, 2008

Page 76

Main Flow: Applicant Enrollment 1. The Applicant appears at the specified enrollment appointment and presents the

Enrollment Reservation Number. 2. The Enrollment Agent presents the Enrollment Reservation Number to the Enrollment

System. 3. The Enrollment System establishes a secure session with the IDMS and requests pre-

enrolled Applicant biographic data from the IDMS using the Applicant’s Enrollment Reservation number.

4. The IDMS returns the requested Applicant biographic data and to the Enrollment System.

5. Applicant presents required identity documents to the Enrollment Agent. 6. The Enrollment Agent scans documents and verifies them against the Applicant

biographic data. 7. The Enrollment Agent captures the Applicant’s ten-print fingerprint biometric & facial

image. 8. The Enrollment Station generates an Enrollment Package consisting of the Applicant

biographic data, fingerprint data, scanned identity documents and facial image. 9. The Enrollment Agent indicates authorization of the enrollment by digitally signing the

Enrollment Package. 10. The Enrollment Station encrypts the Enrollment Package and transmits the signed and

encrypted package to the IDMS. 11. The IDMS verifies the digital signature of the Enrollment Agent on the Enrollment

Package by passing flow to Main Flow: ACIS Signature Verification. 12. Flow passes to Main Flow: Federal Suitability Vetting and the use case ends.

7.2.3 Federal Suitability Vetting

Description: The Federal Suitability Vetting use case performs biometric duplicate check, Security Threat Assessment (STA) and Criminal History Records Check (CHRC) of ACIS Applicants.

Initial Conditions: An ACIS Applicant has been successfully enrolled by an ACIS Enrollment Agent.

End Conditions: Main Flow: Federal Suitability Vetting has been completed.

Actors Involved: Identity Authority IDMS ACIS Central Status Management System (CSMS) TSA - Security Threat Assessment (STA) FBI - Criminal History Records Check (CHRC)


February 27, 2008

Page 77

Use Case Assumptions: All communications employ a secure (authenticated and encrypted) session.

Main Flow: Federal Suitability Vetting 1. The IDMS establishes a secure session with the Central Status Management System

(CSMS) and transmits the Enrollment Package to the CSMS. 2. The CSMS receives the Enrollment Package and generates a temporary Central

Status Management Index (CSMI), a unique CSMS person identifier, to the Applicant. 3. The CSMS generates fingerprint biometric templates from the Applicant fingerprint

images to be used for Automated Fingerprint Identification System (AFIS) fingerprint-based search.

4. The CSMS performs a biometric duplicate check (AFIS 1:n Search) of the Applicant against current ACIS Participants and previously rejected ACIS Applicants using the generated biometric templates.

5. The CSMS generates a list of any match candidate CSMI(s) resulting from the AFIS Search.

6. The CSMS forwards the Enrollment Package to the TSA along with list of AFIS matching candidates.

7. The TSA adjudicates any AFIS biometric match candidates and assigns the unique match candidate CSMI to the Applicant in the event that a match candidate is confirmed.

8. The TSA forwards the Applicant fingerprints to the FBI for the CHRC and performs a STA.

9. TSA returns the CHRC and STA results to the CSMS, under the assigned CSMI. 10. Upon receipt of the CHRC and STA results, the CSMS assigns the TSA returned

CSMI to the Applicant. 11. The CSMS retains applicant biometrics and STA status under the CSMI, to support

subsequent AFIS search against the Applicant. 12. The CSMS forwards the STA and CHRC results to the requesting IDMS under the

unique CSMI. 13. The IDMS searches its database for an IDMS Person Identifier with the specified

CSMI. 14. If the IDMS finds a matching CSMI, the Applicant is assigned the existing IDMS

Person Identifier. 15. If the IDMS does not find a matching CSMI, the Applicant is assigned a new IDMS

Person Identifier. 16. The IDMS stores the CHRC and STA results for use in Extended Vetting and

Adjudication under the unique IDMS Person Identifier and stores the CSMI, to be used only for future communication with the CSMS regarding the ACIS Applicant/Participant.

17. The CSMS sends signed Reference Biometric Templates to the IDMS and the IDMS stores the templates in the IDMS database.

18. The IDMS acknowledges receipt of the CHRC results, STA results and templates to the CSMS.


February 27, 2008

Page 78

19. Upon acknowledgement of receipt of the CHRC results, STA results and templates, the CSMS deletes Applicant biographic data.

20. Flow passes to Main Flow: Extended Suitability Vetting and Adjudication and the use case ends.

7.2.4 Extended Suitability Vetting and Adjudication

Description: The Extended Suitability Vetting and Adjudication use case performs extended suitability vetting base upon local (Airport) vetting requirements and adjudicates the identity of the ACIS Participant based upon STA, CHRC and extended suitability vetting results.

Initial Conditions: Federal Suitability vetting of an ACIS Applicant has been completed and reported to the IDMS. STA status of green (suitable) or red (unsuitable) has been adjudicated by TSA.

End Conditions: Main Flow: Federal Suitability Vetting has been completed. Alternate Flow Alternate Flow: Applicant Accepted as Suitable. Alternate Flow: Applicant Rejected as Unsuitable.

Actors Involved: Identity Authority IDMS Identity Adjudication System Adjudication Agent Extended Vetting Services ACIS CSMS

Use Case Assumptions: All communications employ a secure (authenticated and encrypted) session. Adjudication status of green for STA, CHRC and Extended Vetting indicates an Applicant is suitable for ACIS participation and local (airport) participation. Adjudication status of red for Extended Vetting indicates Applicant is unsuitable for local (airport) participation. Adjudication status of red for STA or CHRC indicates Applicant is unsuitable for ACIS participation and local (airport) participation. Adjudication status of green for STA and CHRC and red for Extended Vetting indicates Applicant is unsuitable for local participation (Note: Applicant may be suitable for ACIS Participation in another locale).


February 27, 2008

Page 79

Main Flow: Extended Suitability Vetting and Adjudication 1. The IDMS transmit the results of the Federal Suitability Adjudication to the Identity

Adjudication System. 2. The identity Adjudication System initiates extended vetting by requesting Applicant

data from Extended Vetting Services. 3. Upon return of Applicant vetting data from the Extended Vetting Services, the Identity

Adjudication System initiates the adjudication workflow by automatically scoring extended vetting data based upon local vetting rules.

4. If local vetting scores do not meet local thresholds for participation of the Applicant, Extended Vetting Status is set to Red.

5. If local vetting scores meet local thresholds for participation of the Applicant, Extended Vetting Status is set to Green.

6. The Identity Adjudication System automatically compares CHRC results to a list of Federally Disqualify Offenses.

7. If there are disqualifying offenses under Federal rules, CHRC status is set to Red. 8. If there are no disqualifying offenses under Federal rules, CHRC Status is set to

Green. 9. If STA status, CHRC status or Extended Vetting Status indicates Red, flow passes to

Alternate Flow: Adjudication by Adjudication Agent.

Alternate Flow: Applicant Accepted as Suitable 10. Composite Green status (Green STA Status, CHRC Status and Extended Vetting

Status) is digitally signed by the Identity Adjudication System. 11. The Identity Adjudication System signed composite Green status is returned to the

IDMS. 12. The IDMS communicates the composite Green adjudication status to the CSMS

indicating the CSMI of the Applicant. 13. The CSMS updates the Applicant Status stored under the CSMI to indicate successful

completion of Applicant adjudication. 14. The CSMS generates ACIS Reference Biometric Templates from the Applicant 10-

print fingerprint images. 15. The CSMS digitally signs the ACIS Reference Biometric Templates using a TSA

signing key and stores the signature in the template header. 16. The CSMS returns the signed Reference Biometric Templates to the IDMS. 17. Flow passes to Main Flow: Identity Credential Issuance to initiate issuance of the

ACIS Card to the new ACIS Participant and the use case ends.

Alternate Flow: Adjudication by Adjudication Agent 18. The Identity Adjudication System notifies an Adjudication Agent of a pending case

requiring manual adjudication. 19. The Identity Adjudication System presents adjudication case information to the

Adjudication Agent for review and final adjudication of CHRC and Extended Vetting. This may involve communication with the ACIS Applicant (e.g. to resolve disposition of a disqualifying offense).


February 27, 2008

Page 80

20. If the final adjudication results in composite status of Green (Green for STA Status, CHRC Status and Extended Vetting Status), flow passes to Alternate Flow: Applicant accepted as suitable.

Alternate Flow: Applicant Rejected as Unsuitable 21. Applicant and Sponsor are notified of Applicant rejection and provided information

regarding redress process. 22. Final adjudicated composite Red vetting status (Red STA Status, CHRC Status or

Extended Vetting Status) is digitally signed by the ACIS Adjudication Agent. 23. Signed composite adjudication status is returned to the IDMS and stored under the

IDMS Person Identifier of the Applicant. 24. The IDMS communicates the composite Red adjudication status to the CSMS

indicating the CSMI of the Applicant. 25. Flow passes to Main Flow: Subject Revocation and the use case ends.

7.2.5 Identity Credential Issuance

Description: The Identity Credential Issuance use case begins the process of ACIS credential issuance by preparing card data objects to be loaded onto the ACIS card.

Initial Conditions: Identity Adjudication has been completed with a resulting composite Green status.

End Conditions: Main Flow: IDMS has constructed an Identity Credential Issuance Package ready for card personalization.

Actors Involved: Identity Authority IDMS

Use Case Assumptions: The IDMS has previously received signed Reference Biometric Templates from the CSMS and stored the templates in the IDMS database. All communications employ a secure (authenticated and encrypted) session.

Main Flow: Identity Credential Issuance 1. The IDMS prepares the Reference Biometric Templates by storing the local IDMS

Person Identifier in the template header. 2. The IDMS digitally signs the Reference Biometric Templates using the Identity

Authority’s Attribute Authority private signing key. The digital signature replaces the CSMS signature in the template header.


February 27, 2008

Page 81

3. The IDMS generates required card data objects (excluding card certificates) including a Cardholder Unique ID (CHUID) data object for the ACIS Card based upon the IDMS Person Identifier and Printed Information object.

4. The IDMS generates hashes of the CHUID, Printed Information and Facial Image and stores the hashes in the Card Security Object.

5. The IDMS Signs the Card Security Object using the Attribute Authority private signing key.

6. The IDMS prepares a Card Issuance Package containing IDMS generated card data and reference biometrics.

7. The IDMS transmits the Card Issuance Package to the CMS. 8. Flow passes to Main Flow: Card Production and Personalization and the use case

ends.

7.2.6 Card Production and Personalization

Description: The Card Production and Personalization use case begins the process of ACIS card issuance by preparing card data objects to be loaded onto the ACIS credential.

Initial Conditions: The Identity Authority IDMS has delivered a Card Issuance Package to the Identity Authority CMS. Card stock has been manufactured and delivered to the Identity Authority or their designated Card Personalization Service Bureau.

End Conditions: Main Flow: A personalized ACIS Card is ready for activation.

Actors Involved: Identity Credential Issuer IDMS CMS ACIS Card Identity Authority Certificate Authority (CA) Card Production System

Use Case Assumptions: Card production including manufacturing of card body, embedding of ACIS electronic components or other card body features is always performed as an outsourced high volume service by a card manufacturer. Un-personalized ACIS card stock is protected by a Manufacturer Transport Key shared between the Card Manufacturer and the ACIS Identity Credential Issuer.


February 27, 2008

Page 82

ACIS Chip personalization and surface personalization (printing) may occur either as a local process (e.g. as a part of the Identity Authority’s local badge issuance process) or as an outsourced high volume service performed by a Card Personalization Service Bureau. Regardless, card personalization is performed by the Identity Credential Issuer role using a system referred to as the CMS. ACIS chip personalization is always performed under an Identity Credential Issuer key, either controlled directly by the Identity Credential Issuer or by their designated Card Personalization Service Bureau. The Card Manufacturer and Card Personalization Service Bureau may be the same provider, as long as key management processes are properly separated (between manufacturing and personalization). Periodically, card stock is delivered periodically to the Identity Credential Issuer by the Card Manufacturer and placed under inventory control of the CMS. Card stock inventory is managed and is available at the location personalization is performed. The CMS audits all ACIS card stock inventory delivery to and removal activity. As needed, card stock is removed from inventory and provided to the CMS.

Main Flow: Card Production and Personalization 1. The CMS receives an ACIS Card Issuance Package from the IDMS. 2. If the Identity Credential Issuer is an Airport Operator, flow passes to Airport Operator

Personalization.

Main Flow: Aircraft Operator Personalization 3. The CMS or Aircraft Operator legacy system personalizes any Aircraft Operator-

specific features of the Aircraft Operator Card (e.g. magnetic stripe). 4. The CMS performs surface personalization of the ACIS card using ACIS required card

topography. 5. Card surface personalization is inspected for quality control. 6. Flow Passes to Alternate Flow: ACIS Chip Personalization.

Alternate Flow: Airport Operator Personalization 7. The CMS or Airport Operator legacy system performs surface personalization of the

ACIS card based upon local Airport Operator specified SIDA badge topography. 8. The CMS or Airport Operator legacy system personalizes any Airport Operator-

specific features of the Aircraft Operator Card (e.g. magnetic stripe, loadable access control chip).

9. The Airport Operator legacy system (e.g. PACS) performs any Airport Operator-required registration of legacy card features to initialize the legacy physical access control token.

10. Flow Passes to Main Flow: ACIS Chip Personalization.


February 27, 2008

Page 83

Main Flow: ACIS Chip Personalization 11. The CMS authenticates to the ACIS Card using the Manufacturer Transport Key and

establishes a secure channel with the un-personalized ACIS chip (message authentication with encryption) using dynamic session keys.

12. The CMS replaces the Manufacturer Transport Key on the un-personalized ACIS chip with an Identity Credential Issuer Key using the secure channel.

13. The CMS closes the secure channel session with the ACIS Card. 14. The CMS authenticates to the ACIS Card using the Identity Credential Issuer Key and

establishes a secure channel with the ACIS card (message authentication with encryption) using dynamic session keys.

15. The CMS writes IDMS generated data objects (CHUID, Facial Image, Printed Information, security object) to the ACIS card using the secure channel.

16. The CMS generates key pairs for mandatory ACIS ID credential certificates (ACIS Card Authentication and PIV Authentication keys) and constructs certificate requests based upon the generated public keys.

17. The CMS generates proof of possession of the private keys and includes the proof in the certificate request.

18. The CMS authenticates to the Identity Authority CA using a Registration Authority certificate and establishes a secure session for transmission of certificate issuance requests.

19. The CMS requests ACIS Card Authentication and PIV authentication certificates from the Identity Authority CA.

20. The Identity Authority CA verifies proof of possession of the private keys for the requested certificates.

21. The Identity Authority CA constructs and signs the requested certificates and returns them to the CMS.

22. The CMS writes the requested certificates and corresponding private keys to the ACIS card using the secure channel.

23. The CMS generates a temporary Card PIN and writes the PIN to the ACIS card. 24. The CMS stores the temporary Card PIN (or information needed to regenerate the

temporary Card PIN) to be used to unlock the card during card activation. 25. The secure channel card session is closed. 26. If optional ACIS certificates are configured by the Identity Credential Issuer, Alternate

Flow: Optional ACIS Certificate Issuance is performed. 27. Flow passes to Main Flow: Card Activation and the use case ends.

7.2.7 Card Activation

Description: The ACIS Card Activation use case verifies that the legitimate ACIS Participant is in possession of the ACIS Identity Credential and activates the credential for use.


February 27, 2008

Page 84

Initial Conditions: ACIS Identity Credential has been personalized and locked by the CMS using a temporary card PIN.

End Conditions: Main Flow: A personalized ACIS Card is ready for activation.

Actors Involved: Identity Authority CMS Card Activation Station ACIS Activation Agent ACIS Participant ACIS Card

Use Case Assumptions: The ACIS Card has been delivered to the ACIS Participant (referred to as the Cardholder prior to biometric identity verification). Card Activation is attended by an ACIS Activation Agent.

Main Flow: Card Activation 1. The Cardholder inserts the ACIS Card into a contact card reader of the ACIS Card

Activation Station. 2. The Card Activation Station reads the CHUID from the presented card. 3. The Card Activation Station prompts the cardholder to present a live fingerprint

biometric. 4. The Card Activation Station captures the cardholder fingerprint biometric and

generates a fingerprint biometric verification template. 5. The Card Activation Station establishes a secure session with the ACIS CMS and

transmits the CHUID and biometric verification template to the CMS. 6. Using the CHUID as an index, the CMS retrieves the Participant’s reference biometric

template from the CMS database. 7. The CMS matches the cardholder’s verification template against the Participant’s

reference biometric template. (Biometric match to system). 8. If the biometric match is unsuccessful, flow passes to Alternate Flow: Biometric Match

Failed. 9. The CMS prompts the ACIS Participant to enter an initial card PIN. 10. The CMS retrieves (or regenerates) the previously established temporary card PIN

from the CMS database. 11. The CMS sends a PIN change request to the ACIS Card, presenting the temporary pin

and the newly selected card PIN. 12. The Card changes the PIN to the value selected by the ACIS Participant.


February 27, 2008

Page 85

13. The Card Activation Station initiates a Level 3 Identity Verification by passing control to Main Flow: Level 3 Identity Verification in order to verify correct operation of the ACIS Card.

14. If optional ACIS Certificates are required by the Identity Credential Issuer which were not issued during card personalization flow passes to Main Flow: Optional ACIS Certificate Issuance to issue the optional certificates.

15. If the activation is for a re-issued ACIS Card and the Participant is still in possession of the old ACIS Card, flow passes to Alternate Flow: Activation on Re-issuance.

16. CMS session is closed and the use case ends.

Alternate Flow: Activation on Re-issuance. 17. The ACIS Participant provides the old card to the Activation Agent. 18. The Activation Agent presents the card to the ACIS CMS for card termination. 19. The CMS permanently locks the ACIS Card and schedules the card for audited

destruction. 20. The Activation Agent places the ACIS Card under secure inventory control for

destruction. 21. The Identity Credential Issuer securely destroys revoked ACIS Cards and the use

case ends.

Alternate Flow: Biometric Match Failed 22. The Activation Agent directs the Participant to repeat the Card Activation Process. 23. If repeated failures occur, the ACIS Activation Agent initiates necessary steps to

resolve the failure, which may include re-issuance of the ACIS Card and the use case ends.


February 27, 2008

Page 86

7.3 Identity Credential Maintenance Use Cases Identity Credential Maintenance Use Cases comprise use cases to maintain ACIS Identity Credentials. Identity Credential Maintenance use cases are illustrated in the following figure and include:

• PIN change; • Automated PIN unblock, and; • Attended PIN Unblock.

Identity Credential

Usage

Identity Credential

Usage

PIN change needed

ACIS Participant

PIN Change

ACISIdentity

Credential

Attended PIN Unblock

ACISIdentity

Credential

ACISCardholder

Automated PIN Unblock

ACISIdentity

Credential

ACISCardholder


Officer

PIN needs to be unblocked or changed

PIN unblocked needed. Cardholder is identified by fingerprint

Attended PIN unblock needed. Cardholder is identified using

facial image

PIN changed

Card PIN unblocked & replaced by a new PIN

Card PIN unblocked & replaced by a new PIN

ACISIdentity

Credential

PIN available, known to the participant

ACISCardholder

Figure 7-4 Identity Credential Maintenance High Level Flow

7.3.1 PIN Change

Description: ACIS Card PIN needs to be changed by the ACIS Participant

Initial Conditions: The ACIS Card is presented in a contact smart card reader and the PIN is not blocked.


February 27, 2008

Page 87

End Conditions: Main Flow: The PIN is changed to the new user-selected value. Alternate Flow: The PIN change failed.

Actors Involved: ACIS Participant ACIS Card Credential Maintenance Station

Use Case Assumptions: The Credential Maintenance Station is equipped with a means to enter a PIN

Main Flow: PIN Change 1. ACIS Participant inserts his/her ACIS card into a Credential Maintenance Station. 2. The ACIS Participant selects menu option to change the card PIN. 3. The Credential Maintenance Station prompts the ACIS participant for the current PIN

and the new PIN. 4. The ACIS Participant enters old PIN and new PIN according to the Credential

Maintenance Station instructions. 5. The Credential Maintenance Station presents the current PIN and the new PIN the

ACIS Card using the Change Reference Data command. 6. If the current PIN is incorrect the card rejects the PIN change and flow passes to

Alternate Flow: PIN Change Failed. 7. The ACIS Card accepts the command, the new PIN replaces current PIN in the ACIS

card and the use case ends.

Alternate Flow: PIN Change Failed 8. The PIN is not changed and the use case ends.

7.3.2 Automated PIN Unblock

Description: The Automated PIN Unblock use case is used by an ACIS Participant to unblock a card PIN that has been blocked due to repeated entry of an invalid PIN, exceeding the card’s configured PIN retry counter.

Initial Conditions: The card PIN is blocked in the ACIS card.

End Conditions: Main Flow: The PIN is unblocked. Alternate Flow: Automated PIN unblock failed.


February 27, 2008

Page 88

Actors Involved: ACIS Participant ACIS CMS Credential Maintenance Station

Use Case Assumptions: The Credential Maintenance Station is equipped with a means to enter a PIN and to execute a fingerprint biometric verification of the Cardholder.

Main Flow: Automated PIN Unblock 1. ACIS Participant inserts his ACIS card in the Credential Maintenance Station. 2. ACIS Participant selects a menu on the Credential Maintenance Station to reset the

blocked PIN. 3. The Credential Maintenance Station generates a temporary PIN and obtains the PIN

Unblocking Key (PUK) from the CMS. 4. The Credential Maintenance Station presents the PUK along with the temporary PIN

to the ACIS card to reset the PIN. 5. If the PUK is incorrect, the card rejects the command and flow passes to alternate

flow: Automated PIN Unblock Failed. 6. The ACIS Card accepts the command. The PIN reset counter is reset and the

temporary PIN replaces the old PIN in the ACIS card. 7. The Credential Maintenance Station presents the temporary PIN to the ACIS Card. 8. The Identity Credential Maintenance System reads the Participant fingerprint

reference template from the card and verifies the reference template digital signature. 9. If the digital signature is invalid, flow passes to Alternate Flow: Automated PIN

Unblocked Failed 10. The Identity Verification System prompts the cardholder to present a finger on the

biometric scanning device. 11. The Cardholder presents a finger to the biometric scanning device. 12. The Identity Verification System executes the matching algorithm to verify live

fingerprints match the ACIS Participant reference biometric template from the ACIS card.

13. If the fingerprint match fails, flow passes to Alternate Flow: Automated PIN Unblock Failed.

14. The Credential Maintenance Station prompts the ACIS Participant for a new PIN. 15. The ACIS participant chooses a PIN and provides it to the maintenance station. 16. The Credential Maintenance Station executes a PIN change function by presenting

the temporary PIN along with the new PIN to the ACIS card. 17. The ACIS Card accepts the command, the new PIN replaces the temporary PIN in the

ACIS card and the use case ends.

Alternate Flow: Automated PIN Unblock Failed 18. The PIN remains blocked and the use case ends.


February 27, 2008

Page 89

7.3.3 Attended PIN Unblock

Description: The attended PIN Unblock Use Case is used by an ACIS Credential Maintenance Operator to unblock a card PIN that has been blocked due to repeated entry of an invalid PIN, exceeding the card’s configured PIN retry counter. The ACIS Participant is verified by the facial image stored in the ACIS card.

Initial Conditions: The card PIN is blocked in the ACIS card.

End Conditions: Main Flow: The PIN is unblocked. Alternate Flow: The PIN unblock failed.

Actors Involved: ACIS Participant CMS Credential Maintenance Operator Credential Maintenance Station

Use Case Assumptions: The Credential Maintenance Station is equipped with a means to enter a PIN and to display the facial image stored in the card.

Main Flow: Automated PIN Unblock 1. ACIS Credential Maintenance Operator selects the menu to reset a PIN on the

Credential Maintenance Station. 2. ACIS Participant inserts his ACIS card into the Credential Maintenance Station contact

card reader. 3. The Credential Maintenance Station generates a temporary PIN and obtains the PIN

Unblocking Key (PUK) from the Credential Issuer CMS. 4. The Credential Maintenance Station presents the PUK along with the temporary PIN

to the ACIS card. 5. If the PUK is incorrect, the card rejects the command and flow passes to alternate

flow: Automated PIN Unblock Failed. 6. The ACIS Card accepts the command. The PIN reset counter is reset and the

temporary PIN replaces the existing PIN in the ACIS card. 7. The Credential Maintenance Station presents the temporary PIN to the ACIS CARD. 8. The Identity Verification System reads the stored facial image from the card and

displays it to the Credential Maintenance Operator. 9. The Credential Maintenance Operator visually verifies that the facial image displayed

matches the cardholder presenting the card, and the facial photo printed on the card.


February 27, 2008

Page 90

10. If the visual verification fails, flow passes to Alternate Flow: Attended PIN Unblocked Failed.

11. The Credential Maintenance Station prompts the ACIS participant for a new PIN. 12. The ACIS participant chooses a PIN and provides it to the Credential Maintenance

Station. 13. The Credential Maintenance Station prompts the ACIS Participant for a new PIN. 14. The Identity Credential Maintenance Station executes a PIN change function by

presenting the temporary PIN along with the new PIN to the ACIS card. 15. The ACIS Card accepts the command, the new PIN replaces the temporary PIN in the

ACIS card and the use case ends.

Alternate Flow: Attended PIN Unblock Failed 16. The PIN remains blocked and the use case ends.


February 27, 2008

Page 91

7.4 Identity Credential Re-issuance Use Cases Identity Credential Re-issuance use cases comprise use cases to re-issue ACIS Credentials. Re-issuance may be required as a result of loss, theft or damage of the ACIS Card or changes to Participant information. Identity Credential Re-issuance use cases are illustrated in the following figure and include:

• Lost, Stolen or Damaged Card; • Participant Data Update; • Employment Status Change, and; • Identity Credential Re-issuance.

Identity Credential

Usage

New ACISIdentity

Credential

ACISParticipant

Employment Status Change

Identity Credential Revocation

Aviation Employer

ACIS Sponsor

ACIS Sponsor’s

Agent

Agent Revocation

Participant employment status

changes

Credential is revoked due to employment

termination

Agent is revoked if Participant was an

ACIS Agent

Lost, Stolen or Damaged Card

Enrollment Agent

ACISParticipant


Card is lost, stolen or damaged

Identity Credential

Re-issuance

Participant Data Update

Participant biographic or biometric data

changesUpdate requires card to be replaced ACIS

Participant

Update does not require card to be replaced

Identity Credential RevocationOld card is revoked

after new card is issued.

Replacement card is re-issued

Lost, stolen or unusable damaged card is

immediately revoked

Identity Credential

Re-issuanceStatus change requires credential

re-issuance

Replacement card is issued

Update changes employment status

Figure 7-5 Identity Credential Re-issuance High-Level Flow

7.4.1 Lost, Stolen or Damaged Card

Description: An ACIS Credential that is reported lost, stolen or damaged by an ACIS Participant is re-issued.


February 27, 2008

Page 92

Initial Conditions: ACIS Participant has lost possession of an ACIS Card or has an ACIS Card that has been damaged, electrically, mechanically, visually, or does not function.

End Conditions: The lost, stolen or damaged ACIS Card is revoked and a new ACIS Card is issued.

Actors Involved: ACIS Participant Identity Credential Issuer Enrollment Agent ACIS Enrollment System

Use Case Assumptions: If a card is damaged, it is only considered usable if the ACIS chip is functioning correctly. Usability of a card with damage to card surface topography is determined by Identity Authority and Access Control Authority policies. If the Participant does not have a usable ACIS card, the ACIS Sponsor’s Agent takes action to provide temporary means of identification and access control (e.g. temporary card) based upon Identity Authority and Access Control Authority policies.

Main Flow: Lost, Stolen or Damaged Card 1. The ACIS Participant reports the lost, stolen card or damaged card to his or her ACIS

Sponsor. 2. The ACIS Sponsor’s Agent verifies the identity of the Participant using Participant

identity documents (e.g. drivers license, passport) including the damaged card, if available.

3. The ACIS Sponsor’s Agent requests re-issuance of the Participant’s card by sending a signed re-issuance request to the IDMS, indicating loss theft or damage as the reason for re-issuance.

4. If a damaged card is still usable (functioning ACIS chip and topography within policy) the cardholder retains possession of the ACIS Card until a new card is issued.

5. If a damaged card is not usable, the ACIS Sponsor’s Agent returns the damaged card to the Identity Credential Issuer for audited termination and destruction.

6. The Identity Credential Issuer terminates and destroys any returned damaged cards in an auditable fashion.

7. The ACIS IDMS initiates re-issuance of the ACIS Card. Flow passes to Main Flow: Identity Credential re-issuance.

8. The IDMS notifies the requesting Sponsor’s Agent the re-issuance has been requested and the use case ends.


February 27, 2008

Page 93

7.4.2 Participant Data Update

Description: An ACIS Participant has changes to biographic or biometric information which require update of IDMS data records (e.g. name change, address change, change in biometric due to injury). Depending on the nature of the change, a determination is made based upon ACIS Compliance Authority rules and the Participant may need to be re-enrolled and issued a new ACIS Card or re-vetting of the Participant may need to be performed, (e.g. biometric update or name change).

Initial Conditions: Participant information changes have occurred that require the Participant to notify the Identity Credential Issuer.

End Conditions: Main Flow: Participant IDMS data is updated to reflect the information change and allows the existing ACIS Card to continue to be used. Alternate Flow: Participant IDMS data is updated and the change triggered re-enrollment of the Participant and re-issuance of the Participant’s ACIS Card.

Actors Involved: ACIS Participant ACIS Sponsor’s Agent ACIS IDMS

Use Case Assumptions: The ACIS Participant has biographic information which has changed (e.g. name change or contact information) or the Participant biometrics need to be updated (due to injury or due to verification reliability problems using the current Participant fingerprint templates). Updates may change data on the card requiring re-issuance of the card. Updates may change employment status (change sponsorship information originally provided by the ACIS Sponsor).

Main Flow: Participant Data Update 1. The ACIS Participant notifies his or her Sponsor’s Agent of a change to Participant

enrollment data. 2. If the change is to Participant biometric data, flow passes to Alternate Flow: Update

Requires Re-enrollment and Re-issuance. 3. The Sponsor’s Agent initiates a Participant data update by sending a signed request

to the IDMS indicating the type of update required. 4. The IDMS enables Participant update of biographic data. 5. The ACIS Participant provides updated biographic data and submits the data to the

IDMS.


February 27, 2008

Page 94

6. The IDMS verifies that required fields are present in the updated data and records the updated information under the IDMS Person Identifier.

7. If the update changes Participant employment status, flow passes to Alternate Flow: Update Changes Employment Status.

8. If the data update requires change to the information printed on or stored in the ACIS card. Flow passes to Alternate Flow: Update Requires Re-enrollment and Re-issuance.

9. The IDMS updates the Participant biographic data, creates an audit record of the update and the use case ends.

Update Requires Re-enrollment and Re-issuance 10. The IDMS notifies the Sponsor’s Agent of required re-enrollment of the sponsored

Participant and re-issuance of the Participant’s ACIS Card. 11. The Sponsor’s Agent approves the re-enrollment by submitting a signed re-enrollment

authorization to the IDMS. 12. The IDMS creates an audit record of the successful re-enrollment authorization. 13. Flow passes to Main Flow: Identity Credential Re-issuance and the use case ends.

Alternate Flow: Update Changes Employment Status 14. The IDMS notifies that Sponsor’s agent of the change in employment status. 15. Flow passes to Main Flow: Employment Status Change and the use case ends.

7.4.3 Employment Status Change

Description: An ACIS Participant’s employment status changes in a way that changes sponsorship information previously provided by the ACIS Sponsor. Changes can include the employee role, the needed employee access privileges, Participant biographic data or termination of employment with the ACIS Sponsor.

Initial Conditions: An ACIS Sponsor becomes aware of an ACIS Participant’s employment status that must be reported to the Identity Credential Issuer. This may either be triggered directly by the Sponsor or as a result of Participant data changes reported by the Participant.

End Conditions: Main Flow: Participant’s Sponsorship information has been updated and a new ACIS Card has been issued to the Participant. Alternate Flow: Participant’s employment or justification for possession of an ACIS credential has terminated and the Participant’s ACIS Card has been revoked, permanently locked and destroyed.

Actors Involved: ACIS Sponsor’s Agent


February 27, 2008

Page 95

ACIS IDMS ACIS Activation Agent ACIS CMS ACIS Issuer Security Coordinator


Main Flow: Employment Status Change 1. If the employment status change does not terminate employment or justification for

employee possession of an ACIS Card, flow passes to Alternate Flow: Employment Status Change Requires Re-Issuance.

2. The Sponsor’s Agent notifies the IDMS of termination of the employee’s participation in ACIS by submitting a request signed by the Sponsor’s Agent.

3. The IDMS revokes the Participant’s ACIS Card. Flow passes to Main Flow: Identity Credential Revocation.

4. The IDMS deactivates the record for this Participant in the IDMS. 5. If the revoked Participant is an ACIS agent, flow passes to Alternate Flow: Agent

Revocation. 6. The IDMS notifies the ACIS Participant to return his ACIS Card to an Activation Agent. 7. The Activation Agent presents the card to the ACIS CMS in a contact card reader for

card termination. 8. The CMS permanently locks the ACIS Card and schedules the card for audited

destruction. 9. The Activation Agent places the ACIS Card under secure inventory control for

destruction. 10. The Identity Credential Issuer securely destroys revoked ACIS Cards and the use

case ends.

Alternate Flow: Employment Status Change Requires Re-Issuance 11. The Sponsor’s Agent approves re-enrollment of the Participant by submitting a signed

re-enrollment authorization to the IDMS. 12. The IDMS creates an audit record of the successful re-enrollment authorization. 13. The ACIS Participant is re-enrolled and the credential is re-issued. Flow passes to

Main Flow: Identity Credential Re-issuance and the use case ends.

7.4.4 Identity Credential Re-issuance

Description: An ACIS Participant requires a new ACIS Card. This may be because the previous one was lost, stolen or damaged, or because some information related to the ACIS Participant or sponsorship of the ACIS Participant has changed.


February 27, 2008

Page 96

Initial Conditions: Identity credential re-issuance has been requested and approved.

End Conditions: The ACIS Participant has been issued a new ACIS credential.

Actors Involved: ACIS Participant ACIS Sponsor’s Agent ACIS IDMS

Use Case Assumptions: The ACIS Sponsor has provided re-enrollment authorization of the ACIS Participant to the IDMS. The ACIS Participant returns the revoked card to the ACIS Activation Agent at time of activation of the reissued ACIS card.

Main Flow: Identity Credential Re-issuance 1. The IDMS creates an audit record of the successful re-enrollment authorization. 2. If the Identity Credential re-issuance is due to reporting of a lost, stolen or damaged

ACIS card, flow passes to Alternate Flow: Lost, Stolen or Damaged Card. 3. The IDMS generates an Enrollment Reservation Number and provides it to the

Participant, along with available enrollment schedule, instructions and location for enrollment.

4. The ACIS Participant selects a date and time for enrollment and submits to the IDMS. 5. The IDMS confirms the enrollment appointment to the Participant. 6. Re-enrollment of the Participant and re-issuance of the ACIS Card is initiated by the

IDMS. Flow passes to Main Flow: Applicant Enrollment. 7. The IDMS notifies the Sponsor’s Agent that the re-issued Card is available for

activation by the Participant. 8. The Participant appears for card activation. Flow passes to Main Flow: Card

Activation. 9. The IDMS revokes the Participant’s existing ACIS Card. Flow passes to Main Flow:

Identity Credential Revocation. 10. Completion of re-issuance is audited by the IDMS and the use case ends.

Alternate Flow: Lost, Stolen or Damaged Card. 11. The IDMS immediately revokes the Participant’s existing ACIS Card. Flow passes to

Main Flow: Identity Credential Revocation. 12. Re-issuance of the ACIS Card is initiated by the IDMS. Flow passes to Main Flow:

Identity Credential Issuance. 13. The IDMS notifies the Sponsor’s Agent that the re-issued Card is available for

activation by the Participant.


February 27, 2008

Page 97

14. The Participant appears for card activation. Flow passes to Main Flow: Card Activation.

15. Completion of re-issuance is audited by the IDMS and the use case ends.


February 27, 2008

Page 98

7.5 Identity Credential Revocation Use Cases Identity Credential Revocation Use Cases comprise use cases to revoke ACIS Credentials due to termination of ACIS participation and to revoke ACIS participation due to changes in Participant suitability. Identity Credential Revocation use cases are illustrated in the following figure and include:

• Suitability Status Change; • Threat Assessment Status Change; • Identity Credential Revocation; • Subject Revocation, and; • ACIS Agent Revocation.

Threat Assessment

Status Change

Suitability Status Change



TSA STA


Identity Adjudicator

ACIS Adjudication

Agent

Subject Revocation

Agent Revocation

Issuer Security

Coordinator

Issuer Security

CoordinatorSTA

Adjudicator

STA Adjudicator

Issuer Security

Coordinator

Issuer Security

Coordinator


Participant determined unsuitable

Participant STA revoked

Participant determined locally unsuitable

Participant is revoked globally within ACIS

Participant determined Federally unsuitable

Revoked Participant was ACIS Agent

Credentials revoked by all Identity Credential Issuers

Local Identity Credential Issuer revocation

Figure 7-6 Identity Credential Revocation High-Level Flow


February 27, 2008

Page 99

7.5.1 Suitability Status Change

Description: A change in suitability of an ACIS Participant to possess an ACIS Card has been recognized by the issuing ACIS Identity Credential Issuer. A change in suitability requires revocation of the ACIS Participant by the issuing Identity Credential Issuer. Suitability status change requires revocation of the Participant globally within ACIS scheme if the Participant has become unsuitable under Federal suitability rules. For example, a change in suitability triggers revocation of access control privileges by the ACIS Privilege Issuer, in ACIS Phase II,

Initial Conditions: The ACIS Identity Credential Issuer has become aware of a change in suitability of an existing ACIS Participant, by means other than STA revocation by TSA.

End Conditions: Indications of change in suitability have been dismissed and Participant continues participation in ACIS. Indications of change in suitability under extended vetting rules (local Identity Credential Issuer rules) have been confirmed and the Identity Credential Issuer has terminated participation of the ACIS Participant. Indications of change in suitability under Federal suitability rules have been confirmed and the Identity Credential Issuer has informed TSA of the revocation.

Actors Involved: ACIS Issuer Security Coordinator ACIS Adjudication Agent ACIS Identity Adjudication System ACIS Federal Vetting Services Extended Vetting Services

Use Case Assumptions: Termination of participation of an existing ACIS Participant as unsuitable requires approval by an Adjudication Agent and approval by the Issuer Security Coordinator.

Main Flow: Suitability Status Change 1. Indication of unsuitability of the Participant is adjudicated by an ACIS Adjudication

Agent. 2. The adjudication submits a signed adjudication result to the Identity Adjudication

System indicating adjudicated Federal and Extended suitability status. 3. Adjudication results are reviewed by the Issuer Security Coordinator.


February 27, 2008

Page 100

4. The Issuer Security Coordinator either approves or rejects the Identity Adjudicator’s suitability determination by providing a signed authorization to the Identity Adjudication System.

5. The Identity Adjudication System submits approved suitability determination to the IDMS.

6. If the Participant is found to be suitable, flow passes to Alternate Flow: Suitability Status Unchanged.

7. If the Participant has been determined to be unsuitable, the ACIS IDMS updates the Participant suitability status in the IDMS database to indicate Participant termination due to the adjudicated unsuitability.

8. The ACIS IDMS initiates revocation of the Participant’s ACIS credentials. Flow passes to Main Flow: Identity Credential Revocation.

9. If the revoked Participant was acting as an ACIS Agent, Flow passes to Main Flow: ACIS Agent Revocation.

10. If the adjudicated suitability status indicated Federal unsuitability of the Participant, Flow Passes to Main Flow: Subject Revocation to initiate cascaded revocation the Participant across the ACIS scheme.

11. The IDMS audits completion of the Participant revocation and the use case ends.

Alternate Flow: Suitability Status Unchanged 12. The IDMS audits the completion of the suitability status change process and the use

case ends.

7.5.2 Threat Assessment Status Change

Description The threat assessment status of an ACIS Participant can change as a result of perpetual vetting of the ACIS Participant by the TSA. Upon TSA recognition of a change in threat assessment status, the ACIS CSMS reports the status change to all ACIS Identity Credential Issuers who have issued ACIS credentials to the Participant. The ACIS Identity Credential Issuer(s) initiate revocation of the Participant. Revocation of the Participant by Identity Credential Issuers triggers revocation of access control privileges in ACIS Phase II by all ACIS Privilege Issuer’s who have used the ACIS Participant credentials to grant access control privileges.

Initial Conditions: The TSA Screening Gateway has reported a change in STA status to the ACIS CSMS.

End Conditions: Participant is revoked by all issuing ACIS Identity Credential Issuers. Access Control privileges are revoked by all ACIS Privilege Issuers.

Actors Involved: TSA Screening Gateway


February 27, 2008

Page 101

Central Management Status System


Main Flow: Threat Assessment Status Change 1. The CSMS receives an STA status change notification from the TSA Screening

Gateway indicating the CSMS Index of the ACIS Participant. 2. The CSMS Initiates revocation of the ACIS Participant by all ACIS Identity Credential

Issuers who have issued credential to the ACIS Participant. Flow Passes to Main Flow: Subject Revocation.

3. The CSMS audits the completion of the subject revocation and the use case ends.

7.5.3 Identity Credential Revocation

Description: The Identity Credential Revocation Use Case revokes an ACIS Identity Credential. The action of revoking the Identity Credential revokes not only ACIS chip functions but all use of the ACIS Card. Identity Credential revocation is triggered by card re-issuance due to loss, theft or damage to the ACIS Card or card re-issuance resulting from changes in Participant data, or employment status including normal termination of participation due to termination of employment. Identity Credential revocation is also triggered by changes in Participant suitability.

Initial Conditions: Identity Credential revocation has been requested as a result of one of the triggering events above.

End Conditions: Main Flow: Participant’s ACIS Identity Credential has been revoked with revocation status published to a Certificate Revocation List (CRL).

Actors Involved: ACIS IDMS ACIS CMS Identity Authority CA

Use Case Assumptions: Revocation has been approved by the appropriate ACIS Agent(s).

Main Flow: Identity Credential Revocation 1. The IDMS receives a request to revoke an ACIS credential.


February 27, 2008

Page 102

2. The IDMS verifies the digital signature on the revocation request and verifies that the requesting agent is authorized to make the request.

3. The IDMS submits a revocation request to the CMS. 4. The CMS identifies the ACIS Card and ACIS certificates associated with the

requested revocation. 5. The CMS submits revocation requests to the Identity Authority CA for each ACIS

Certificate. 6. The Identity Authority CA performs revocation of the requested certificates. 7. The CMS schedules the ACIS Card for permanent locking. The next time the card is

seen by the CMS in an on-line transaction, the CMS will permanently lock the card. 8. The CMS returns the status of the revocation to the IDMS. 9. The IDMS logs the status of the ACIS Credential in the IDMS database and audits the

completion of revocation. 10. The IDMS returns completion status to the initiating use case and the use case ends.

7.5.4 Subject Revocation

Description: The Subject Revocation use case revokes the participation of a subject (ACIS Participant) globally across the ACIS scheme. Subject Revocation may be triggered by changes in Participant suitability status as adjudicated by the Identity Credential Issuer or STA status changes adjudicated by TSA. When a Participant is determined to be unsuitable under an ACIS Identity Authority’s local rules (Extended Vetting) the subject is revoked only within the scope of the ACIS Identity Credential Issuer. If the Participant is still Federally Suitable, the Participant may apply and be issued ACIS credentials by other ACIS Identity Credential Issuers. If the Participant is determined to be unsuitable under Federal rules (or STA status change), the participation is revoked locally by the Identity Credential Issuer and then revoked globally through a subject revocation cascade initiated by the ACIS CSMS.

Initial Conditions: Subject revocation request has been submitted to the CSMS, either by an Identity Credential Issuer (Federal unsuitability) or by the TSA Screening Gateway (STA Status Change).

End Conditions: Main Flow: ACIS Participant’s (subject) suitability and participation is revoked globally within the ACIS scheme.

Actors Involved: Issuer Security Coordinator ACIS Adjudication Agent ACIS IDMS ACIS CMS


February 27, 2008

Page 103

Use Case Assumptions: Subject revocation requests initiated by an ACIS Identity Credential Issuer have been approved and digitally signed by the ACIS Issuer Security Coordinator. Subject revocation requests initiated for STA status changes have been approved by TSA. Subject revocation requests initiated by an ACIS Identity Credential Issuer resulting in cascaded global revocation of ACIS participation must be approved by TSA prior to initiation of the global revocation cascade by the CSMS. Subject revocation requests initiated by an ACIS Identity Credential Issuer resulting in cascaded global revocation of ACIS participation, are approved by each Identity Credential Issuer that has previously adjudicated suitability of the Participant prior to initiation of local participant revocation.

Main Flow: Subject Revocation 1. The CSMS determines which ACIS Identity Credential Issuer(s) have issued ACIS

credentials to the Participant based upon the CSMS Index. 2. The CSMS updates the Participant record in the CSMS database to indicate STA

status change of the Participant. 3. The CSMS sends subject revocation requests to the IDMS of each of the Identity

Credential Issuers (excepting the Credential Issuer initiating the subject revocation due to Federal unsuitability determination).

4. The IDMS of each Identity Credential Issuer receives the subject revocation and updates the Participant Status to indicate initiation of subject revocation.

5. If the reason for subject revocation is an STA status change, flow passes to Alternate Flow: STA Revocation.

6. The IDMS of each Identity Credential Issuer sends the revocation for review by an ACIS Adjudication Agent and approval by the Issuer Security Coordinator.

7. If the Identity Credential Issuer does not concur with the suitability determination, flow passes to Alternate Flow: Suitability Adjudication Resolution.

8. The Issuer Security Coordinator of each Identity Credential Issuer approves the subject revocation by submitting a digitally signed subject revocation approval to the Identity Adjudication System.

9. The Identity Adjudication system forwards the subject revocation request to the IDMS.

Alternate Flow: STA Revocation 10. The IDMS updates Participant status to indicate termination of participation. 11. The IDMS initiates revocation of the Participant’s ACIS Card. Flow passes to Identity

Credential Revocation. 12. The IDMS notifies the Participant and the Participant’s Sponsor of the revocation and

course of action for redress. 13. If the Participant is an ACIS Agent, flow passes to Main Flow: Agent Revocation 14. The IDMS of each Identity Credential Issuer acknowledges completion of subject

revocation to the CSMS.


February 27, 2008

Page 104

15. The CSMS receives acknowledgement from each IDMS, updates the Participant status and the use case ends.

Alternate Flow: Suitability Adjudication Resolution 16. The Issuer Security Coordinator contacts TSA to resolve the suitability determination

and takes required action (revoke or not) based upon the resolution.

7.5.5 ACIS Agent Revocation

Description: The Agent Revocation Use Case revokes an ACIS Agent when the participation is revoked of an ACIS Participant who is an ACIS Agent. When the Agent’s ACIS credential has been revoked, determination of unsuitability brings into question previous actions taken by the Participant acting as an Agent, particularly in cases where the suitability change triggering the Agent revocation is due to an STA status change.

Initial Conditions: Subject revocation request has been approved by the Issuer Security Coordinator and the ACIS Participant’s credentials have been revoked.

End Conditions: ACIS Agent status has been removed from the IDMS and Participant actions as an ACIS Agent have been reviewed by the Issuer Security Coordinator.

Actors Involved: ACIS IDMS Issuer Security Coordinator

Use Case Assumptions: None

Main Flow: ACIS Agent Revocation 1. The ACIS IDMS removes Agent assignments associated with the revoked ACIS

Participant. 2. If the revoked agent was not revoked due to suitability status change or STA status

change, flow passes to Alternate Flow: Normal Agent Termination. 3. The ACIS IDMS provides details of agent actions performed by the ACIS Participant

for review of the Issuer Security Coordinator. 4. The Issuer Security Coordinator reviews the Agent actions and takes any steps

necessary based upon the review (e.g. Participants enrolled by the revoked agent could be re-enrolled).

Alternate Flow: Normal Agent Termination 5. The IDMS audits completion of the Agent revocation and the use case ends.


February 27, 2008

Page 105

8 ACIS Phase II Use Cases ACIS Phase II use cases comprise usage of the ACIS Identity Credential issued during ACIS Phase I. Phase II use case categories include:

• Identity Credential Usage Use Cases - Challenge of an individual’s identity using biometrics and cryptographic card authentication and Identity Verification in PACS registration to support automated revocation of PACS privileges when an Identity Credential is revoked.

• Digital Signature Subordinate Use Cases – Signature functions supporting the chain of trust in Identity Credential usage.

• Identity Verification Subordinate Use Cases – Verification functions supporting identity verification at graduated identity authentication assurance levels.




UsageUse Cases

Identity Credential

UsageUse Cases

Digital Signature




Use Cases

Sponsor Approval

Use Cases

Identity Credential


Identity Credential






Figure 8-1 ACIS Phase II Use Cases Categories

ACIS Phase II use cases assume the ACIS Card contains the ACIS Identity application used in Phases I and use cases from Phase I continue to be supported.


February 27, 2008

Page 106

8.1 Identity Credential Usage Use Cases Identity Credential Usage Use Cases perform challenge of an individual’s identity using biometrics and cryptographic card authentication. Identity Credential Usage Use Cases also perform identity verification in PACS registration to support automated revocation of PACS privileges when an Identity Credential is revoked. Identity Credential Usage use cases are illustrated in the following figure and include:

• Identity Verification Spot Check; • Identity Credential PACS Registration; • Identity Credential PACS De-registration, and; • PACS Privilege Revocation.



Identity Verification Spot Check

Identity Credential

PACSDe-registration

ACISParticipant

Identity Credential

PACS Registration

Identity Credential life cycle begins

Cardholder identity challenge using Identity Credential and biometric

Identity Credential is registered in PACS

Identity Credential is removed from PACS

PACS Privilege Revocation

Identity revocation triggers privilege revocation

Identity Credential

Maintenance

Identity Credential

Usage

ACISIdentity

Credential

ACISIdentity

Credential

Identity Credential is revoked

ACISCardholder

ACISIdentity

CredentialACIS

Participant


Officer

Identity Credential life

cycle continues

PACS Registration

Agent

PACS Registration

Agent

Figure 8-2 Identity Credential Usage High-Level Flow


February 27, 2008

Page 107

8.1.1 Identity Verification Spot Check

Description: The Identity Verification Spot Checking use case allows an Identity Verification Officer (e.g. airport law enforcement officer) to spot-check the identity of an ACIS cardholder using card authentication, and PIN/biometric verification.

Initial Conditions: The cardholder subject to verification has an ACIS Identity Credential. The Identity Verification Operator has an ACIS verification device able to interact with ACIS Identity Credentials.

End Conditions: Main Flow: Identity verification spot check successful Alternate Flow: Identity verification spot check negative

Actors Involved: ACIS Identity Verification Officer ACIS Identity Verification Device ACIS Cardholder ACIS Participant

Use Case Assumptions: The ACIS verification device may be a mobile or fixed station. The ACIS verification device supports card authentication, certificate validation, PIN entry and biometric verification. Spot check uses card and biometric verification with PIN.

Main Flow: Identity Verification Spot Check 1. The Identity Verification Officer challenges a cardholder to verify that they are the

legitimate bearer of an ACIS Credential. 2. The Identity Verification Officer initiates identity verification using card authentication

and biometric verification with PIN. Flow passes to subordinate use case at Main Flow: Level 3 Identity Verification.

3. If Identity verification is not successful, flow passes to Alternate Flow: Identity Verification Spot Check Negative.

4. The identity verification device indicates successful verification to the Identity Verification Officer.

5. The identity verification success is audited by the identity verification device and the use case ends.


February 27, 2008

Page 108

Alternate Flow: Identity Verification Spot Check Negative 6. The identity verification device indicates failed identity verification to the Identity

Verification Officer. 7. The identity verification failure is audited by the identity verification device 8. The Identity Verification Officer takes the appropriate action as specified by the Airport

Security Plan and the use case ends.

8.1.2 Identity Credential PACS Registration

Description: An ACIS participant presents his or her ACIS Identity card and a justification for access to a PACS registration agent.

Initial Conditions: ACIS participant has a justification to access an area controlled by a PACS. ACIS participant has an ACIS credential which is not useable as an access control card in the local PACS.

End Conditions: Main Flow: Identity Credential PACS registration is successful. Alternate Flow: Identity Credential PACS registration failed.

Actors Involved: ACIS Participant ACIS Card PACS Registration Agent ACIS PACS Registration System

Use Case Assumptions: The PACS is able to accept ACIS Identity cards as identity documents and register them. An Identity Verification System is integrated with the PACS.

Main Flow: Identity Credential PACS Registration 1. ACIS participant presents to the PACS registration agent its justification for access. 2. The PACS registration agent verifies documentation justifying granting of access and

asks participant to introduce his/her card into the Identity Verification System. 3. The PACS executes a Level 3 Identity Verification. Flow passes to Main Flow: Level 3

Identity Verification. 4. If Identity verification is not successful, flow passes to alternate flow: PACS

registration failed. 5. The PACS Registration System registers the ACIS Participant for local access

privilege, stores the reference information (CHUID) of the ACIS Card presented.


February 27, 2008

Page 109

6. The PACS may optionally transfer biometric and biographic information to its data base (facial image, fingerprints, PACS PIN, etc.) from the ACIS card for use in the access control system.

7. The PACS may create a local access control badge for the Participant according to local PACS requirements.

8. The use case ends.

Alternate Flow: Identity Credential PACS registration failed 9. The ACIS participant is denied request for unescorted access by the PACS

Registration Agent. 10. No local access privilege is created, the identity credential is not registered in the

PACS and the use case ends.

8.1.3 Identity Credential PACS De-registration

Description: Access control privilege attached to a given ACIS Identity Credential is to be canceled and the ACIS identity credential reference removed from the PACS.

Initial Conditions: An ACIS participant has local access privileges in a PACS.

End Conditions: Main Flow: Identity Credential PACS de-registration

Actors Involved: PACS Registration Agent PACS Registration System ACIS PACS

Use Case Assumptions: An ACIS Participant is registered for local access privileges in a PACS.

Main Flow: Identity Credential PACS De-registration 1. The PACS Registration Agent provides the ACIS Card reference to the PACS

Registration System. 2. The PACS Registration System displays local access privileges (if any) existing for the

ACIS Participant. 3. The PACS Registration Agent confirms deactivation (revocation) of the local access

privilege. 4. The PACS Registration System removes (or mark as inactive) the ACIS Card

reference information (CHUID) from the PACS data base. 5. The PACS revokes local access control privileges and the use case ends.


February 27, 2008

Page 110

8.1.4 PACS Privilege Revocation

Description: An ACIS Identity Credential has been revoked and all local access control privileges granted to the corresponding ACIS participant shall be revoked.

Initial Conditions: An ACIS Identity Credential is revoked.

End Conditions: Main Flow: PACS Privilege Revocation

Actors Involved: ACIS Validation Authority ACIS PACS Registration System

Use Case Assumptions: On a regular basis, the PACS Registration System validates (using CRL or OCSP) all ACIS Credentials used to grant local access control privileges. Upon revocation of an ACIS Identity Credential by an ACIS Identity Authority, the credential is placed upon a CRL accessible to the PACS Registration System and the ACIS Validation Authority.

Main Flow: PACS Privilege Revocation 1. The PACS Registration System accesses an updated CRL or initiates an OCSP

request to the ACIS Validation Authority to determine if registered Identity Credentials have been revoked.

2. The PACS revokes all local privileges attached to any ACIS Identity credentials that have been revoked and the use case ends.


February 27, 2008

Page 111

8.2 Digital Signature Subordinate Use Cases Digital Signature Subordinate Use Cases perform digital signature functions supporting the chain of trust in Identity Credential usage. Digital Signature Subordinate Use Cases are illustrated in the following figure and include:

• ACIS Digital Signature, and; • ACIS Signature Verification.

ACIS Signature Verification

ACIS Digital Signature

ACIS Participant provides card PIN to

sign data

Signed data is returned to the

initiating use case

Initiating Use Case

Initiating Use Case

Use case requests digital signature

ACIS Participant

Initiating Use Case

Use case requests signature

verification

Initiating Use Case

ACISIdentity

Credential

Signed Data

Signature is verified

Signature verification status is returned to the

initiating use case

Unsigned Data

Signed Data

Verified Data

Figure 8-3 Digital Signature High-Level Flow

8.2.1 ACIS Digital Signature

Description: The ACIS Participant digitally signs information.


February 27, 2008

Page 112

Initial Conditions: ACIS Participant needs to digitally sign information.

End Conditions: An ACIS Digital Signature is applied to data.

Actors Involved: ACIS Participant ACIS Card ACIS Computer System

Use Case Assumptions: An ACIS Computer System is any computer system or application within ACIS requiring a digital signature to be applied by an ACIS Participant. ACIS Participant has the digital signature keys enabled in his/her ACIS card (e.g. ACIS Agent). ACIS Participant has an active ACIS card, and has been authenticated by an ACIS Computer System which contains information that needs to be digitally signed.

Main Flow: ACIS Digital Signature 1. The ACIS Participant indicates to the ACIS Computer System he/she is ready to sign

information. 2. The ACIS Computer System calculates hash of information to sign. 3. The ACIS Computer System presents the ACIS Participant with the details (including

hash) about the information to be signed and requests the ACIS Participant to sign the information.

4. The ACIS Participant indicates consent for signing the information by entering the ACIS card PIN.

5. The ACIS Computer System presents PIN entered to ACIS card. 6. The ACIS Computer System reads the digital signature certificate from the card. 7. The ACIS Computer System requests the ACIS card to execute a signature on the

information hash. 8. The ACIS Computer System attaches resulting signature and the certificate to the

information and stores the result for further processing.

8.2.2 ACIS Signature Verification

Description: An ACIS Computer System needs to verify a digital signature attached to submitted information received from an ACIS Participant or other ACIS Computer System.


February 27, 2008

Page 113

Initial Conditions: Authenticity of a digital signature on ACIS signed information needs to be verified.

End Conditions: Main Flow: ACIS Signature Verification Successful. Alternate Flow: Signature Verification failed.

Actors Involved: ACIS Computer System ACIS Validation Authority

Use Case Assumptions: An ACIS Computer System is any computer system or application within ACIS requiring verification of a digital signature. ACIS digitally signed information is available in an ACIS Computer System.

Main Flow: ACIS Signature Verification 1. Digital signature attached to received ACIS information needs to be verified 2. The ACIS Computer System accesses the information to verify. 3. The ACIS Computer System calculates hash of received information. 4. The ACIS Computer System reads certificate attached to received information and

requests a check of the validity by the ACIS Validation Authority. 5. If certificate is not valid, flow passes to alternate flow: Signature Verification Failed. 6. The ACIS Computer System verifies signature is correct 7. If the signature is not valid, flow passes to Alternate Flow: Signature Verification Failed 8. Digital signature valid status is returned to the initiating use case and the use case

ends.

Alternate Flow: Signature Verification Failed 9. Digital signature invalid status is returned to the initiating use case and the use case

ends.


February 27, 2008

Page 114

8.3 Identity Verification Subordinate Use Cases Identity Verification Subordinate Use Cases perform verification functions supporting identity verification at graduated identity authentication assurance levels in both attended and unattended situations. Identity Verification Subordinate Use Cases are illustrated in the following figure and include:

• Level 1 Identity Verification; • Level 2 Identity Verification; • Level 3 Identity Verification, and; • Level 3 Attended Identity Verification.

Initiating Use Case

Initiating Use Case

Single-factor authentication

requested

ACIS Participant

Level 1 Identity Verification

ACISIdentity

Credential


ACISIdentity

Credential

ACISCardholder


ACISIdentity

Credential

ACISCardholder

Level 3 Attended Identity

Verification

ACISCardholder

ACISIdentity

Credential


Officer

Cardholder identity verification requested

Two-factor authentication

requested

Three-factor authentication

requested

Three-factor authentication using

face requested

Card is authenticated

Card authenticated, card PIN verified

Card authenticated, card PIN verified, fingerprint verified

Card authenticated, card PIN verified,

facial image verified

ACISIdentity

Credential

Card authenticated, cardholder optionally

verified

Figure 8-4 Identity Verification Subordinate Use Cases


February 27, 2008

Page 115

8.3.1 Level 1 Identity Verification

Description: The Level 1 Identity Verification authenticates the ACIS card using active ACIS card authentication of the Card Authentication Certificate. (Note that the cardholder is not verified in Level 1 Identity Verification)

Initial Conditions: An Identity Verification System has requested Level 1 verification of a Cardholder.

End Conditions: Main Flow: Successful Card Verification is returned to the requesting Identity Verification System. Alternate Flow: Card Verification failure is returned to the requesting application.

Actors Involved: Cardholder ACIS Credential ACIS Validation Authority ACIS Identity Verification Operator ACIS Identity Verification System

Use Case Assumptions: The Identity Verification System is using either Credential Revocation List (CRL) or OCSP mechanisms to check for revocations.

Main Flow: Level 1 Identity Verification 1. The Identity Verification System prompts the user to insert an ACIS card in the contact

smart card reader. 2. The Cardholder inserts his/her ACIS card in the contact reader of the Identity

Verification System. 3. The Identity Verification System selects the ACIS card-application, reads the CHUID

and verifies this is an active (not revoked) authentic (signature is correct) ACIS CHUID.

4. If the CHUID is not valid or revoked, flow passes to Alternate Flow: Level 1 Identity Verification Failed.

5. The Identity Verification System reads the card authentication certificate and verifies the certificate is not revoked and it refers to the card CHUID read previously.

6. If the certificate is invalid or does not point to correct the CHUID, flow passes to Alternate Flow: Card Verification Failed.

7. The Identity Verification System executes an active card authentication. 8. If card authentication fails, flow passes to Alternate Flow: Level 1 Identity Verification

Failed.


February 27, 2008

Page 116

9. The Identity Verification System indicates verification success to the Cardholder. 10. Success of card verification is returned to the requesting Identity Verification System

and the use case ends.

Alternate Flow: Level 1 Identity Verification Failed 11. The Identity Verification System logs the failed verification. 12. The Identity Verification System indicates verification failure to the Cardholder and the

use case ends. 13. Failure of card verification is returned to the requesting Identity Verification System



Description: The ACIS Level 2 Identity Verification executes an active ACIS card authentication after the participant has provided a PIN to the ACIS card.

Initial Conditions: An Identity Verification System has requested Level 2 verification of an ACIS card that has been presented by a Cardholder.

End Conditions: Main Flow: Identity verification with Card PIN is successful. Alternate Flow: Identity verification with Card PIN is not successful.

Actors Involved: Cardholder ACIS Credential ACIS Identity Verification System

Use Case Assumptions: The Identity Verification System is using either CRL or OCSP mechanisms to check for revocations. The Identity Verification System has a Pin-Pad for the cardholder to present a PIN.


smart card reader. 2. Cardholder inserts his/her ACIS card in the contact reader of the Identity Verification

System. 3. The Identity Verification System verifies the card works, using answer to reset (ATR),

selects the ACIS card-application, reads the CHUID and verifies this is an ACTIVE (not revoked) true (signature is correct) ACIS card.


February 27, 2008

Page 117

4. If the CHUID is not valid or revoked, flow passes to Alternate Flow: Identity Verification using Card PIN failed.

5. The Identity Verification System prompts the Cardholder for the ACIS card PIN. 6. Cardholder presents the card PIN on pin-pad. 7. The Identity Verification System presents the PIN to the ACIS card. 8. If PIN entered is incorrect, the Identity Verification System prompts the Cardholder to

re-enter the PIN. If PIN retry count is exceeded, the card locks and flow passes to Alternate Flow: Level 2 Identity Verification failed.

9. The Identity Verification System reads the Participant's authentication certificate from the card and verifies the certificate is not revoked and refers to the card CHUID read previously.

10. If certificate is invalid or does not point to correct CHUID, flow passes to Alternate Flow: Level 2 Identity Verification Failed.

11. The Identity Verification System executes an active card authentication. 12. If authentication fails, flow passes to Alternate Flow: Level 2 Identity Verification

Failed. 13. The Identity Verification System indicates verification success to the Cardholder. 14. Success of card verification is returned to the requesting Identity Verification System






Description: The Level 3 Identity Verification authenticates the ACIS Card using active card authentication. After the participant has provided consent (card PIN) to the ACIS card, Level 3 Identity Verification verifies that the fingerprint of the cardholder matches the reference biometric template of the ACIS Participant stored in the card.

Initial Conditions: An Identity Verification System has requested an ACIS Level 3 Identity Verification to verify the card presented is a legitimate ACIS card and is presented by the legitimate ACIS Participant.

End Conditions: Main Flow: Identity verification with card authentication and fingerprint biometric match is successful.


February 27, 2008

Page 118

Alternate Flow: Identity verification with card authentication and fingerprint biometric match is not successful.

Actors Involved: Cardholder ACIS Credential ACIS Validation Authority ACIS Identity Verification System

Use Case Assumptions: The Identity Verification System is using either CRL or OCSP mechanisms to check for revocations. The Identity Verification Station has a PIN-Pad for the cardholder to present a PIN. The Identity Verification Station has a biometric device able to capture and verify the cardholder live fingerprint against the reference biometric template stored in the ACIS card.



Verification System. 3. Identity verification system selects the ACIS card-application, reads the CHUID and

verifies this is an ACTIVE (not revoked) authentic (signature is correct) ACIS CHUID. 4. If the CHUID is not valid or revoked, flow passes to Alternate Flow: Level 3 Identity

Verification Failed. 5. The Identity Verification System prompts the Cardholder for the ACIS card PIN. 6. The Cardholder presents the card PIN on the pin-pad. 7. The Identity Verification System presents the PIN to the ACIS Card. 8. If the PIN entered is incorrect, the Identity Verification System prompts the Cardholder

to re-enter the PIN. If PIN retry count is exceeded, the card locks and flow passes to Alternate Flow: Level 3 Identity Verification Failed.

9. The Identity Verification System reads the Participant fingerprint reference template from the card, verifies the digital signature and that it refers to the verified CHUID.

10. If the digital signature is invalid, flow passes to Alternate Flow: Level 3 Identity Verification Failed.

11. The Identity Verification System prompts the cardholder to present a finger on the biometric scanning device.

12. The Cardholder presents a finger to the biometric scanning device. 13. The Identity Verification System verifies that the presented fingerprint matches the

ACIS participant reference biometric template from the ACIS card. 14. If the fingerprint match fails, flow passes to Alternate Flow: Level 3 Identity Verification

Failed.


February 27, 2008

Page 119

15. The Identity Verification System reads the Participant's authentication certificate from the card and verifies the certificate is not revoked and that it refers to the verified CHUID.

16. If the certificate is invalid or does not point to the correct CHUID, flow passes to Alternate Flow: Level 3 Identity Verification Failed.

17. The Identity Verification System executes an active card authentication. 18. If the authentication fails, flow passes to Alternate Flow: Level 3 Identity Verification

Failed. 19. The Identity Verification System indicates verification success to the Cardholder. 20. Success of card verification is returned to the requesting Identity Verification System





8.3.4 Level 3 Attended Identity Verification

Description: The Level 3 Attended Identity Verification provides an alternate Level 3 biometric verification of ACIS Participants who do not have usable fingerprint biometrics. The Level 3 Attended Identity Verification executes an active ACIS card authentication after the Participant has provided consent by a PIN entry to release the facial image stored in the ACIS card. The facial image is visually compared against the Cardholder’s face and the photo printed on the ACIS card, and verified by an ACIS Identity Verification Officer.

Initial Conditions: An Identity Verification System has requested an ACIS Level 3 verification of an ACIS Cardholder, to verify the card presented is a legitimate ACIS card and that it is presented by the legitimate ACIS Participant.

End Conditions: Main Flow: ACIS Participant identity verification with facial image is successful. Alternate Flow: Cardholder identity verification with facial image is not successful.

Actors Involved: Cardholder ACIS Card ACIS Validation Authority ACIS Identity Verification Operator ACIS Identity Verification System


February 27, 2008

Page 120

Use Case Assumptions: The Identity Verification System is using either CRL or OCSP mechanisms to check for revocations. The Identity Verification System has a PIN-Pad for the cardholder to present a PIN. The Identity Verification System has a means to visually display the facial image stored in the ACIS card for viewing by the Identity Verification Operator.

Main Flow: Level 3 Attended Identity Verification 1. The Identity Verification System prompts the user to insert an ACIS card in the contact


Verification System. 3. The Identity Verification System verifies the card works, using answer to reset (ATR),

selects the ACIS card-application, reads the CHUID and verifies this is an ACTIVE (not revoked) authentic (signature is correct) ACIS CHUID.

4. If the CHUID is not valid or is revoked, flow passes to Alternate Flow: Level 3 Attended Identity Verification Failed.

5. The Identity Verification System prompts the Cardholder for the ACIS Card PIN. 6. Cardholder presents the card PIN on the pin-pad. 7. The Identity Verification System presents the PIN to the ACIS card. 8. If the PIN entered is incorrect, the Identity Verification System prompts the Cardholder

to re-enter the PIN. If the PIN retry count is exceeded, the card locks and flow passes to Alternate Flow: Level 3 Attended Identity Verification Failed.

9. The Identity Verification System reads the Participant facial image from the card, verifies the digital signature and that it refers to the verified CHUID.

10. If the facial image is incorrect or the signature invalid, flow passes to Alternate Flow: Level 3 Attended Identity Verification Failed.

11. The Identity Verification System displays the facial image from the card. 12. The Identity Verification Operator visually verifies the facial image displayed matches

the cardholder’s face and the photo printed on the ACIS card. 13. If visual verification of the facial image fails, flow passes to Alternate Flow: Level 3

Attended Identity Verification Failed. 14. The Identity Verification System reads the Participant's authentication certificate from

the card and verifies the certificate is not revoked and it refers to the verified CHUID. 15. If the certificate is invalid or does not point to the correct CHUID, flow passes to

Alternate Flow: Level 3 Attended Identity Verification Failed. 16. Identity Verification System executes an active card authentication. 17. If the authentication fails, flow passes to Alternate Flow: Level 3 Attended Identity

Verification Failed. 18. The Identity Verification System indicates verification success to the ACIS Participant

and the Identity Verification Operator. 19. Success of card verification is returned to the requesting Identity Verification System



February 27, 2008

Page 121

Alternate Flow: Level 3 Attended Identity Verification Failed 20. The Identity Verification System logs the failed verification. 21. The Identity Verification System indicates verification failure to the Cardholder and the

Identity Verification Operator. 22. Failure of card verification is returned to the requesting Identity Verification System



February 27, 2008

Page 122

9 ACIS Phase III Use Cases ACIS Phase III use cases comprise use cases involving registration and use of ACIS Cards (Privilege Credentials) as Physical Access Control System tokens supporting cryptographic card authentication and biometric cardholder verification in Airport access control systems. Phase III use cases categories include:

• Privilege Credential Registration Use Cases - Mutual registration between the ACIS Card and a PACS to initiate use of the ACIS Card as a PACS token.

• Privilege Credential Usage Use Cases – Verification functions supporting privilege verification at graduated authentication assurance levels.




UsageUse Cases

Identity Credential

UsageUse Cases

Digital Signature




Use Cases

Sponsor Approval

Use Cases

Identity Credential


Identity Credential






Figure 9-1 ACIS Phase II Use Cases Categories

ACIS Phase III use cases assume the ACIS card contains the privilege application features in addition to the ACIS Identity Card-application used in Phases I and II and that all use cases from all previous phases continue to be supported.


February 27, 2008

Page 123

9.1 Privilege Credential Registration Use Cases Privilege Credential Registration Use Cases perform mutual registration between the ACIS Card and a PACS to initiate use of the ACIS Card (ACIS Privilege Credential) as a PACS token. Privilege Credential Registration Use Cases are illustrated in the following figure and include:

• Privilege Credential PACS Registration; • Privilege Credential Registration at Issuance, and; • Privilege Credential Deletion.


Identity and Privilege

Credential Usage

Access privilege requested post-issuance

Privilege Credential DeletionACIS


ACISParticipant

Access privilege terminated


Registration at Issuance

PACS and ACIS card updated at ACIS Card issuance

Privilege deleted in ACIS Card and PACS

Identity Credential

Usage

ACISPrivilege

Credential

ACISParticipant


PACS Registration

PACS and ACIS Card updated, Privilege created in ACIS Card

ACISParticipant

ACISIdentity

Credential

ACISIdentity

Credential

ACISParticipant

Identity Credential

Usage

ACISPrivilege

Credential

Access privilege requested pre-issuance

ACISIdentity

Credential

PACS Registration

Agent

Figure 9-2 Privilege Credential Registration High-Level Flow

9.1.1 Privilege Credential PACS Registration

Description: In ACIS Phase III the ACIS Card and the local PACS perform a mutual registration. In addition to the PACS registering the ACIS Identity Credential (as in ACIS Phase II), the ACIS Credential registers the PACS local identifiers and keys in its memory, allowing the


February 27, 2008

Page 124

ACIS credential to be used as a local physical access control token using card authentication and biometric verification.

Initial Conditions: The ACIS Participant with a Phase III ACIS Card has justification to be granted access privileges by an airport PACS.

End Conditions: Main Flow: The ACIS Credential is mutually registered with the PACS for use as an access control token. Alternate Flow: Privilege credential PACS registration failed.

Actors involved ACIS Participant ACIS Card PACS Registration Agent ACIS PACS Registration System

Use Case Assumptions: Phase 3 ACIS Cards are used as ACIS Identity Credentials and the PACS Registration System is able to generate local access privileges according to the protocol of the Phase 3 ACIS Privilege Card-Application.

Main Flow: Privilege Credential PACS Registration 1. The ACIS Participant presents justification for access to the PACS Registration Agent. 2. The PACS Registration Agent verifies the justification and asks participant to introduce

his/her card into the contact smart card reader of the PACS Registration System. 3. The PACS Registration System executes a Level 3 Identity Verification. Flow passes

to Main Flow: Level 3 Identity Verification. 4. If identity verification is not successful, flow passes to Alternate Flow: Privilege

Credential PACS Registration Failed. 5. The PACS Registration System registers the ACIS Participant for access privilege and

stores the reference (CHUID) of the ACIS Card presented. 6. The PACS Registration System creates an entry for a local access control privilege in

its database. 7. The PACS Registration System provides its PACS Identifier to the ACIS Identity

Credential Issuer which has issued the ACIS Credential presented and requests a card session key to communicate with the ACIS Credential.

8. The ACIS Identity Credential Issuer creates a card session key and ciphers it with a key known by the ACIS Credential. The ACIS Identity Credential Issuer also ciphers the PACS Identifier with the credential key and sends the ciphered information (session key and PACS identifier) along with the card session key in clear text to the PACS Registration System.


February 27, 2008

Page 125

9. The PACS Registration System uses the card session key provided to cipher the local PACS diversified authentication key to be used by the ACIS Privilege Application for mutual authentication.

10. The PACS Registration System sends the ciphered session key from the ACIS credential issuer and the ciphered local PACS diversified key ciphered by the card session key to the card.

11. The PACS Registration System sends the local PACS identifier, the local access privilege identifier, and the local algorithm identifier to the card in clear text.

12. The ACIS Card deciphers the session key and the ciphered PACS identifier and verifies the PACS identifier matches the PACS identifier provided in clear text, and uses the provided session key to decipher the local PACS diversified authentication key.

13. The ACIS Card then stores the entry for the PACS (PACS Identifier, Privilege Identifier, Algorithm and local PACS authentication key) in its privilege table.

14. If the ACIS Credential is not successful in registering the PACS, the entry is cleared in the ACIS Credential and the flow passes to Alternate Flow: Privilege Credential PACS Registration Failed.

15. The PACS may optionally transfer biometric and biographic information to its data base (facial image, fingerprints, PACS PIN, etc.) from the ACIS card for use in the access control system.

16. The ACIS identity credential with a privilege is ready for use and the use case ends.

Alternate Flow: Privilege Credential PACS Registration Failed 17. Any temporary PACS entry related to the ACIS Credential registration is cleared. 18. The ACIS participant is denied request for access without escort and ACIS card is not

registered in PACS.

9.1.2 Privilege Credential Registration at Issuance

Description: When the ACIS Identity Authority is the same entity as the ACIS Access Control Authority (an Airport issued ACIS credential is being used at the Identity Credential Issuer’s airport) , a PACS access control privilege can be loaded on the ACIS Credential at the time of ACIS Credential issuance. This process allows ACIS Privilege Credentials to be registered in advance of use without an attended registration process.

Initial Conditions: An ACIS Credential is required to work in a given PACS as a local access control token. ACIS Local PACS keys and PACS Identifiers have been shared with the ACIS Identity Credential Issuer by the ACIS Privilege Issuer.

End Conditions: Main Flow: Privilege Credential PACS registration at issuance is successful. Alternate Flow: Privilege Credential PACS registration at issuance failed.


February 27, 2008

Page 126

Actors involved ACIS Card ACIS CMS ACIS PACS Registration System

Use Case Assumptions: During ACIS Credential issuance the ACIS CMS/IDMS has access to privilege information in order to pre-load the information as a part of ACIS Credential Issuance. The ACIS Identity Authority is also the local Access Control Authority which will use the credential for physical access control and the ACIS Participant is eligible for a local access control privileges.

Main Flow: Privilege Credential Registration at Issuance 1. The ACIS credential is issued according to Phase I Identity Credential Issuance

followed by the Phase I Card Production and Personalization. 2. ACIS CMS creates a card session key and ciphers it with a key known by the ACIS

Credential. The ACIS CMS also ciphers the PACS Identifier with the credential key and sends the ciphered information (session key and PACS identifier) along with the card session key to the PACS Registration System in clear text.

3. The ACIS Identity Credential is presented to the PACS Registration System. 4. The PACS Registration System verifies the ACIS Credential is genuine by executing a

Level 1 Identity Verification (active ACIS card authentication). 5. The PACS Registration System creates a local access privilege entry for the ACIS

credential. The entry is identified with a local privilege identifier. 6. The PACS Registration System uses the card session key to cipher the local PACS

diversified authentication key to be used by the ACIS privilege application for mutual authentication.

7. The PACS sends the ciphered session key from the ACIS CMS (Identity Credential Issuer) and the local PACS diversified key ciphered by the card session key to the ACIS Card.

8. The PACS Registration System sends the local PACS identifier, the local access privilege identifier, and the local algorithm identifier to the card in clear text.

9. The ACIS card deciphers the session key and the ciphered PACS identifier. The ACIS Card verifies the ciphered PACS identifier matches the PACS identifier provided in clear text, and uses the provided session key to decipher the local PACS diversified authentication session key.

10. The ACIS Card then stores the entry for the PACS (PACS Identifier, Privilege Identifier, Algorithm, PACS authentication key) in its privilege table.

11. If ACIS credential is not successful in registering the PACS, the entry is cleared in the ACIS Credential and the flow passes to Alternate Flow: Privilege Credential Registration at Issuance Failed.

12. The ACIS identity credential with a privilege is ready for activation and the use case ends.


February 27, 2008

Page 127

Alternate Flow: Privilege Credential Registration at Issuance Failed 13. Any temporary PACS entry related to the ACIS Credential registration is cleared. 14. The ACIS Participant registers the credential manually using Main Flow: Privilege

Credential PACS Registration and the use case ends.

9.1.3 Privilege Credential Deletion

Description: A privilege credential is removed from an ACIS Credential.

Initial Conditions: ACIS Participant needs to remove a local PACS access privilege from its ACIS credential.

End Conditions: Main Flow: Privilege credential is deleted from the ACIS Card.

Actors Involved: ACIS Participant ACIS Credential Maintenance System

Use Case Assumptions: A Phase III ACIS Credential is used. The ACIS participant has access to an ACIS Credential Maintenance System with an application allowing removal of an ACIS privilege from an ACIS card.

Main Flow: Privilege Credential Deletion 1. The ACIS Participant introduces his/her ACIS card into the contact card reader of the

ACIS Credential Maintenance System and selects in the ACIS function to delete a privilege in an ACIS Card.

2. The ACIS Credential Maintenance System prompts the user for the PACS Identifier of the privilege to be removed.

3. The ACIS Participant enters the PACS Identifier of the privilege to be removed. 4. The ACIS Credential Maintenance System presents this information to the ACIS Card

as a parameter of a command deleting a privilege in the ACIS Card. 5. If the PACS Identifier is found in the ACIS card, the privilege attached to the entry is

removed, the previous information is erased and the entry is freed in the ACIS Card’s privilege table.

6. The PACS Identifier and the associated privilege is removed form the ACIS card and the use case ends.


February 27, 2008

Page 128

9.2 Privilege Credential Usage Privilege Credential Usage Use Cases perform verification functions supporting privilege verification at graduated authentication assurance levels in both attended and unattended situations. Privilege Credential Usage Use Cases are illustrated in the following figure and include:

• Level 1 Card Privilege Verification; • Level 2 Card Privilege Verification; • Level 2 Biometric Privilege Verification; • Level 2 Attended Privilege Verification, and; • Level 3 Biometric Privilege Verification;


System Use Case

PACS requires cardholder privilege

verification


required without biometric


required

Three-factor authentication

required

Level 1 Privilege

VerificationACISPrivilege

Credential

Card authenticated without cardholder verification

Level 2 Card Privilege


Credential

ACISCardholder

Card authenticated, PACS PIN verified

Level 2 Biometric Privilege


Credential

ACISCardholder

Card authenticated fingerprint verified

Level 3 Biometric Privilege

Verification

ACISCardholder

ACISPrivilege

Credential Card authenticated, PACS PIN verified, fingerprint verified


required, unusable fingerprints

Level 2 Attended Privilege


Credential

ACISCardholder

Card authenticated, facial image verified


System Use Case

ACISPrivilege

Credential

ACIS Participant

Card authenticated and/or cardholder

verified

Single-factor authentication

required


Officer

Figure 9-3 Privilege Credential Usage High-Level Flow


February 27, 2008

Page 129

9.2.1 Level 1 Card Privilege Verification

Description: An ACIS Participant uses an ACIS card for physical access control using mutual authentication.

Initial Conditions: The ACIS Participant has a Phase III ACIS Card in which a privilege application for a given PACS has been loaded during Privilege Credential PACS Registration or Privilege Credential Registration at Issuance.

End Conditions: Main Flow: Level 1 Card privilege verification is successful. Alternate Flow: Level 1 Card privilege verification is unsuccessful.

Actors Involved: ACIS Cardholder ACIS Privilege Verification System

Use Case Assumptions: The ACIS Privilege Verification System is a physical access control reader device using either a contact or a contactless smart card interface.

Main Flow: Level 1 Card Privilege Verification 1. The ACIS Card is presented to a Privilege Verification System by a Cardholder. 2. The Privilege Verification System prompts the cardholder to place the ACIS Card on

the terminal antenna or in a contact smart card reader. 3. The Cardholder places the card on the designated area or reader slot. 4. The Privilege Verification System selects the ACIS card application and provides the

PACS Identifier of the connected PACS to the ACIS Card. 5. The ACIS Card selects the context specific to the PACS Identifier and notifies the

Privilege Verification System that it has done so. 6. The Privilege Verification System and the ACIS Card perform a mutual authentication

and establish a session key. 7. The Privilege Verification System asks the card application to provide the local

privilege number under which this ACIS Card is known. 8. The ACIS Card provides this number ciphered by the previously established session

key. 9. The Privilege Verification System deciphers the information and checks the local

access privilege number against its local data base. 10. If the local access privilege number provided is valid and active in the local PACS data

base the card authentication is successful, access is granted to the cardholder and the use case ends.


February 27, 2008

Page 130

Alternate Flow: Level 1 Card Privilege Verification Failed 11. If any verification fails, the card authentication fails and the access is not granted.

9.2.2 Level 2 Card Privilege Verification

Description: An ACIS participant uses an ACIS Card for physical access control in an area requiring PIN knowledge. The PIN used is the PACS PIN.

Initial Conditions: The ACIS Participant has a Phase III ACIS Card in which a privilege application for a given PACS has been loaded during Privilege Credential PACS Registration or Privilege Credential Registration at Issuance. ACIS Participant has created a PACS PIN during the PACS registration.

End Conditions: Main Flow: Level 2 Card Privilege Verification is successful. Alternate Flow: Level 2 Card Privilege Verification is unsuccessful.


Use Case Assumptions: The ACIS Privilege Verification System is a physical access control reader device using either a contact or a contactless smart card interface. The Privilege Verification System has a pin pad.

Main Flow: Level 2 Card Privilege Verification 1. The ACIS Card is presented to a Privilege Verification System by a Cardholder. 2. The Privilege Verification System prompts the cardholder to place the ACIS Card on






key.


February 27, 2008

Page 131

9. The Privilege Verification System deciphers the information and checks the local access privilege number against its local data base.

10. The Privilege Verification System prompts the user to enter the PACS PIN on the terminal pin-pad.

11. The Cardholder enters the PACS PIN on the pin-pad. 12. The Privilege Verification System verifies this is the correct PACS PIN associated to

the local access control privilege number. 13. If the local access privilege number provided is valid and the PACS PIN is correct, the

authentication is successful, access is granted and the use case ends.

Alternate Flow: Level 2 Card Privilege Verification Failed 14. If any verification fails, the authentication process fails, the access is not granted and

the use case ends.

9.2.3 Level 2 Biometric Privilege Verification

Description: An ACIS participant uses an ACIS Card for physical access control in an area requiring biometric verification.


End Conditions: Main Flow: Level 2 Biometric Privilege Verification is successful. Alternate Flow: Level 2 Biometric Privilege Verification is unsuccessful.


Use Case Assumptions: The ACIS Privilege Verification System is a physical access control reader device using either a contact or a contactless smart card interface. The Privilege Verification System has a fingerprint biometric interface.

Main Flow: Level 2 Biometric Privilege Verification 1. The ACIS Card is presented to a Privilege Verification System by a Cardholder. 2. The Privilege Verification System prompts the cardholder to place the ACIS Card on

the terminal antenna or in a contact smart card reader. 3. The Cardholder places the card on the designated area or reader slot.


February 27, 2008

Page 132

4. The Privilege Verification System selects the ACIS card application and provides the PACS Identifier of the connected PACS to the ACIS Card.

5. The ACIS Card selects the context specific to the PACS Identifier and notifies the Privilege Verification System that it has done so.

6. The Privilege Verification System and the ACIS Card perform a mutual authentication and establish a session key.

7. The Privilege Verification System asks the card application to provide the local privilege number under which this ACIS Card is known.

8. The ACIS Card provides this number ciphered by the previously established session key.

9. The Privilege Verification System asks the ACIS Card to provide the reference fingerprint information related to the ACIS participant.

10. The ACIS Card ciphers the fingerprint reference template using the established current session key and sends it to the Privilege Verification System.


12. The Privilege Verification System prompts the user to present a finger on the fingerprint scanner.

13. The Cardholder presents the finger on the scanning device. 14. The Privilege Verification System verifies the live fingerprint matches the reference

fingerprint. 15. If the local access privilege number provided is valid and the fingerprint matches, the

authentication is successful, access is granted and the use case ends.

Alternate Flow: Level 2 Biometric Privilege Verification Failed 16. If any verification fails, the authentication process fails, the access is not granted and

the use case ends.

9.2.4 Level 2 Attended Privilege Verification

Description: An ACIS Participant uses an ACIS Card for physical access control in an area requiring biometric verification but fingerprints cannot be used.


End Conditions: Main Flow: Level 2 Attended Biometric Privilege Verification is successful. Alternate Flow: Level 2 Attended Biometric Privilege Verification is unsuccessful.


February 27, 2008

Page 133

Actors Involved: ACIS Cardholder Identity Verification Operator ACIS Privilege Verification System

Use Case Assumptions: The ACIS Privilege Verification System is a physical access control reader device using either a contact or a contactless smart card interface. The Privilege Verification System is operated by an Identity Verification Operator.

Main Flow: Level 2 Attended Biometric Privilege Verification 1. The ACIS Card is presented to a Privilege Verification System by a Cardholder. 2. The Privilege Verification System prompts the cardholder to place the ACIS Card on






key. 9. The Privilege Verification System asks the card to provide the facial Image of the

ACIS Participant. 10. The ACIS Card ciphers the facial image and sends it to the Privilege Verification

System. 11. The Privilege Verification System deciphers the information and checks the local

access privilege number against its local data base. 12. The Privilege Verification System deciphers the facial image, verifies its signature and

sends it to the Identity Verification Operator for display. 13. The Identity Verification Operator verifies the facial image matches the cardholder. 14. If the local access privilege number provided is valid and the cardholder matches the

facial image matches, the authentication is successful, access is granted and the use case ends.

Alternate Flow: Level 2 Attended Privilege Verification Failed 15. If any verification fails, the authentication process fails, the access is not granted and

the use case ends.


February 27, 2008

Page 134

9.2.5 Level 3 Biometric Privilege Verification

Description: ACIS Participant uses an ACIS Card for physical access control in an area requiring biometric verification and knowledge of a PACS PIN.

Initial Conditions: The ACIS Participant has a Phase III ACIS Card in which a privilege application for a given PACS has been loaded during Privilege Credential PACS Registration or Privilege Credential Registration at Issuance. ACIS Participant has created a PACS PIN during the PACS registration.

End Conditions: Main Flow: Level 3 Biometric Privilege Verification with PACS PIN is successful. Alternate Flow: Level 3 Biometric Privilege Verification is unsuccessful.

Actors Involved: ACIS Cardholder Privilege Verification System

Use Case Assumptions: The ACIS Privilege Verification System is a physical access control reader device using either a contact or a contactless smart card interface. The Privilege Verification System has a fingerprint biometric interface and a PIN PAD.

Main Flow: Level 3 Biometric Privilege Verification 1. The ACIS Card is presented to a Privilege Verification System by a Cardholder. 2. The Privilege Verification System prompts the cardholder to place the ACIS Card on






key. 9. The Privilege Verification System asks the card to provide the reference fingerprint

information related to the ACIS Participant.


February 27, 2008

Page 135

10. The ACIS Card ciphers the fingerprint reference template and sends it to the Privilege Verification System.


12. The Privilege Verification System prompts the user to present a finger on the fingerprint scanner.

13. The Cardholder presents the finger on the scanning device. 14. The Privilege Verification System verifies the live fingerprint matches the reference

fingerprint. 15. The Privilege Verification System prompts the user to enter the PACS PIN on the

terminal pin-pad. 16. The Cardholder enters the PACS PIN on the pin-pad. 17. The Privilege Verification System verifies this is the correct PACS PIN associated to

the local access control privilege number. 18. If the local access privilege number provided is valid, the fingerprint matches, and the

PIN is correct, the authentication is successful, access is granted and the use case ends.

Alternate Flow: Level 3 Biometric Privilege Verification Failed 19. If any verification fails, the authentication process fails, the access is not granted and

the use case ends.


February 27, 2008

Page A-1

Appendix A - ACIS Card Data Model The ACIS Data Model is based on the PIV data model described in the NIST SP 800-73-2 document. This appendix uses a similar organization to SP800-73-2 in which differences, when they exist, are indicated.

A.1 Introduction The ACIS card application has two different versions. This Appendix describes the ACIS card application introduced in ACIS Phase I and called ACIS Identity Card application (ACIS card application version 1) that provides functionality for the ACIS identity credential. It contains all the elements and functions required to use the ACIS credential as an identity credential. The ACIS card application used in Phase III is called ACIS Privilege Card Application (or ACIS card application version 2) and provides on the top of the identity functionalities available in the version 1, local access control functions for PACS providing security and confidentiality under locally managed keys. This card application is not defined in details as this time. The ACIS privilege card application (ACIS card application Version 2) will add PACS functionality to the ACIS card application version 1, so as to allow the ACIS card to support the functions described in Appendix C of this document. The following sections of this appendix describe the ACIS Card application version 1. The ACIS card application version 2 will have additional functionalities but be backward compatible with this specification for the identity credential functionalities.

A.2 ACIS Card Application Identifier The ACIS name space is defined within the application identifier defined for the ACIS card application and managed by TSA. The Application Identifier used for the ACIS card application is:

TSA Registered Application Issuer (RID) A0 00 00 03 67 Group for non TSA employee applications 20 00 ACIS Application identifier 00 02 ACIS application release 00 or 80 (for tests) ACIS application version 1 01

The full AID of the ACIS card application for version 1 is: A0 00 00 03 67 20 00 00 02 00 01 for live cards, or; A0 00 00 03 67 20 00 00 02 80 01 for test cards

The ACIS card application may be selected by the full AID or the AID without the last two bytes (release and version). It is highly recommended for client applications to use a truncated ACIS AID with a length of 9 bytes for the selection, as the card will return the release and version of the ACIS application selected in the card. As for PIV, only one ACIS application can reside in the ACIS card.

A.3 ACIS Card Application Name Space Within the name space defined by the ACIS application identifier, the following rules for names do apply: The file names (called by PIV container IDs) are separated in two categories:


February 27, 2008

Page A-2

• ACIS file reserved names, and; • ACIS issuer’s specific files.

In order to provide a backward compatibility with PIV names, all file names from 0x0001 to 0xDFFF are reserved for ACIS and should not be used by any issuer files within the ACIS application. The issuer is allowed to add files (or containers) with names in the range of 0xE000 to 0xFFE0. The BER-TLV Tags allowed in the ACIS card application falls in four different categories:

• ANS.1 or ISO/IEC 7816 BER-TLV reserved tags; • PIV defined tags (they are in a coexistent allocation scheme with ISO/IEC 7816); • ACIS application reserved tags are all in the ASN.1 proprietary class and with a tag value

from 0x00 to 0x30 (tags 0xC0 to 0xDE). The corresponding constructed tags are reserved as well for ACIS use (tag values from 0xE0 to 0xFE);

• ACIS Issuer available tags are all in the ASN.1 proprietary class and with a tag value from 0x31 to 0x127 (tags 0xDF1F to 0xDF7F). The corresponding constructed tags are reserved as well for application issuer purpose (tags 0xFF1F to 0xFF7F).

The ACIS specification does not impose or suggests client applications to use a common API interface and as such does not need to define OIDs as in PIV. Client applications willing to use (or develop) a PIV-aligned API working with the ACIS credential will have to either be limited to the defined PIV OIDs or to define their own OIDs (any OID structure compliant with ANS.1 Object Identifier will most likely fit a translation table in a PIV compliant middleware). Another solution is to modify (if possible) the middleware PIVAPI and use an API more aligned with ISO/IEC 24727 using directly the card application existing ANS.1 tags (or the EFIDs) defined as data objects at the interface.

A.4 ACIS Data Model Elements The ACIS card application uses the same data objects as PIV on the contact interface but is different on the contactless interface which is completely optional (not required) in ACIS. Some data objects optional in PIV are mandatory in the ACIS application and conversely but when they are used in ACIS they are identical to PIV in use and structure than PIV with one minor exception. The ACIS card application shall have seven mandatory interoperable data objects in all cards:

• Card Holder Unique Identifier; • Card Holder Facial Information; • Printed information; • X.509 Certificate for ACIS card authentication; • X.509 Certificate for ACIS card and user authentication; • Card Holder Fingerprint I and II, and; • Security Object.

The following ACIS interoperable optional data objects which may be present in an ACIS card are:

• Card Capability Container;


February 27, 2008

Page A-3

• X.509 Certificate for PIV Digital Signature; • X.509 Certificate for PIV Key Management, and; • Unsigned Card Holder Unique Identifier.

The following sections provide a description of the ACIS data Objects.

Card Capability Container This data object is defined and maintained by the Federal government for backward compatibility with GSC-IS specification. As ACIS does not have the rights to allocate a new data model number in the Card Capability container, its use is rather limited to ACIS and its presence is made optional.

Card Holder Unique Identifier This data object has a similar structure and purpose as the CHUID defined in PIV which is to identify the credential within a given issuer numbering space. The structure uses an airport/airline identifier instead of agency identifiers in the organization identifier and (as PIV recommends). It should not have any permanent user identifier in the CHUID but only a credential identifier. As the issuing airport/airline identifier is part of this data structure, it provides a unique identifier for the credential as well as identification of the card issuer. As such the CHUID points uniquely to the individual to which it was issued and this number is considered in ACIS as personally identifiable information. To protect the privacy and security of the credential, this information is provided in clear text only on the contact card interface in order to provide backward compatibility with PIV. The physical presentation of the card to a contact reader by the user is considered “user consent” and this action allows the release of this information. Cardholder Unique ID structure is as follows. + The Agency code of the CHUID is ‘9999’ indicating a non-federal issuing entity. + The Organization Identifier (OI) of the CHUID (tag 32) is mandatory in ACIS and is used to identify the identity authority which has vetted the identity represented in the credential. The first byte indicates the nature of the organization issuing the credential. The structure of this identifier is coded on four bytes as follows:

• 0x00 is reserved for FAA and is not used at this point in time and the three following bytes are coded as three zeros.

• 0x10 indicates the credential is issued by an Airport Operator. The three following bytes are coded in ASCI using the World Wide Airport Identifier of the airport (e.g. for Louisa, Virginia the airport code is ‘LOW’ and OI will be coded as OI = 0x104C4F57).

• 0x20 indicates the credential is issued by an Aircraft Operator. The three following bytes are coded in ASCI using the IATA Airline code (e.g. for Aloha Airlines the airline code is ‘AAH’ and OI will be coded as OI = 0x20414148).

• 0x30 indicates the credential is issued by (or for) a third party logistical companies. The three following bytes are coded in ASCII using the IATA 3PL code of the company.

Note: This code is shown for coding purpose showing it is possible for a third party logistic company to become an ACIS identity authority which is not an aircraft of airport operator (e.g. aircraft manufacturer). As all ACIS identity authorities have to be accredited by TSA, this coding is there just to show this is technically possible.


February 27, 2008

Page A-4

• 0xFF is Reserved for TSA and the only valid code allowed at this time is a code reserved for test (card not valid as a credential) with the three other bytes coded as ones (OI = 0xFFFFFFFF).

• All other codes are reserved for future use and should not be used.

+ The various elements of the FASC-N (coded in 5 bits BCD) contained in the CHUID are: • Agency code = 9999 (non Federal Entity). • System code = is coded as 0x9999 for identity authorities not managing a PACS and not

willing to use the CHUID as an access control identifier. For Identity Authorities willing to use the CHUID as an access control identifier, this represents the PACS reference number in case the access control authority needs/wants to manage multiple separate PACS entities under the same Organization Identifier (OI).

• Credential Number (6 BCD digits) is allocated by the identity authority. • CS (Series code indicating the system version) is always = ‘1’. • ICI (Credential code) is always =’1’. • The value of the Personal Identifier (PI) is ’0000000000’ (ten BCD zero digits). • The organization category (OC) is always ‘3’ indicating a commercial category. • The organization identifier (OI) is always ‘3’ indicating a company. • The Personnel Category is used by ACIS to indicate the category to which the cardholder

belongs:

1. Employee of the identity authority (aircraft or airport operator) 2. Employee of an external employer (employer indicated in DUNS) 3. Executive Staff 4. Uniformed Service (police, Firefighter, etc.) 5. Contractor 6. Six and higher, reserved for future use.

+ The GUID is all zeros but is mandatory as in PIV. + The DUNS field is not required when the sponsor is the identity authority. The DUNS field is mandatory otherwise and shall be used to indicate the name/identifier of the employer (sponsor) of the cardholder when he/she is not an employee of the identity authority. The name coded on this 9 byte field shall be coded in ASCII but is not standardized as a whole and is under the direct control of each identity authority (local codification). + The Authentication Key Map is optional and not used by ACIS. + The expiration date is mandatory (tag 0x35) and is coded on 8 bytes in ASCII format YYYYMMDD. + The CHUID is signed using the same technique described in FIPS 201, with the signature field containing the issuer’s certificate.

Note: The credential number shall be unique for one given system code. The system code shall be unique for one given Organization Identifier.


February 27, 2008

Page A-5

Card Holder Facial Information This data object, mandatory in ACIS, has an access protected by the user PIN presentation, is available in clear text on the contact interface and is built in accordance with FIPS 201 (as in PIV). This information is provided in order to allow a complete electronic secure identity verification of the cardholder along with other printed information appearing on the ACIS card. The detail of printed zones and tags are indicated in the data model section.

Printed Information This data object, mandatory in ACIS, has an access protected by the user PIN presentation is available in clear text on the contact interface and is built in accordance with FIPS 201 (as in PIV). This information is provided in order to allow a complete electronic secure identity verification of the cardholder along with the printed information appearing on the ACIS card.

X.509 Certificate for ACIS card authentication This data object contains an X.509 certificate if the card authentication key is an asymmetric key. It contains information about the algorithm, key length and key version to use if the key is a symmetric key. No user consent is required in order to use this key. This data object is always available on the contact interface.

X.509 Certificate for ACIS card and user authentication This certificate is a Public Key certificate used to authenticate actively (challenge response) the card after the correct PIN has been presented by the user to the ACIS card application. It allows an indirect authentication of the user (PIN knowledge) and of the ACIS card as a genuine ACIS card (private key knowledge) in one operation. (This key is called in FIPS 201 the PIV authentication key).

Card Holder Fingerprint I and II This data object is identical in structure, name and access conditions to the corresponding PIV data object.

Security Object This data object is used to provide certification of origin for up to 16 data objects in the ACIS card application. It is built using the container IDs assigned to the various data objects and can be used to check which optional data objects are present in the ACIS card. It is built using the same rules and mechanisms as in PIV. As in PIV it is not available on the contactless interface.

X.509 Certificate for PIV Digital Signature This certificate and its associated private key are used by ACIS participants to generate digital signatures attached to documents. This is an optional feature which is used by ACIS Participants having a role in which they need to digitally sign documents. This feature is a requirement for all ACIS agents.

Note: PIV requires user participation each time this function executed. This requires the PIN to be presented each time this function is to be executed. As there is no way for the card to know if the PIN was presented by the user or cached and re-presented when required by the middleware, this “PIN Always” feature is allowed for PIV compatibility but is not required in ACIS cards.


February 27, 2008

Page A-6

X.509 Certificate for PIV key management As in PIV, this certificate and associated key are for encryption (in order to provide confidentiality) of information transmitted by or to the ACIS card. As for PIV, the use of this key is subject to user consent and requires the correct PIN to be presented.

Unsigned Card Holder Unique Identifier This element is optional in ACIS cards on the contact interface and its content and structure are ruled by the same criteria as the signed CHUID.

A.5 Data Object Containers Data object containers, tags, access control rules and interface modes are summarized in the following table.

Container Name

Container ID

BER-TLV Tag

Access rule

Contact/ Contactless

Mandatory/ Optional

Card Capability Container 0xDB00 0x5FC107 Always

read Contact *Optional

CHUID 0x3000 0x5FC102 Always read *Contact Mandatory

Unsigned CHUID 0x3002 0x5FC104 Always read *Contact Optional

ACIS user & card Authentication 0x0101 0x5FC105 PIN Contact Mandatory

Fingerprint 0x6010 0x5FC103 PIN Contact Mandatory Printed Information 0x3001 0x5FC109 PIN Contact *Mandatory

Facial Image 0x6030 0x5FC108 PIN Contact *Mandatory Digital Signature certificate 0x0100 0x5FC10A Always

read Contact Optional

Key Management certificate 0x0102 0x5FC10B Always

read Contact Optional

ACIS card authentication 0x0500 0x5FC101 Always

read *Contact *Mandatory

Security Object 0x9000 0x5FC106 Always read Contact Mandatory

Note: Cells with a black background in this table indicate a departure from PIV (NIST 800-73-2).

A.6 Data Object Representation As for PIV, all ACIS data objects are identified using a BER-TLV tag defined by PIV or within the ACIS card application (AID) name space. But ACIS data objects do not have a data object identifier attached to them outside of this name space. As a consequence they do not have ACIS allocated OIDs (Object Identifiers as defined in the ANS.1 specification). PIV OIDs may be used for ACIS data objects defined in PIV.


February 27, 2008

Page A-7

In PIV as well as in this specification there is a one to one correspondence between a container ID and the BER-TLV tag used to reference the information accessible in the container. This double name space may seem redundant but comes from the choices of the PIV command set and is maintained for compatibility purpose in this specification. In the ACIS specification, the access control rules attached to the container ID (and as such to the BER-TLV tag it contains) apply to all the elementary ACIS data objects they contain. This is important to notice as in future releases of the ACIS specification it will be possible for an ACIS container to contain more than one ACIS elementary or constructed data object (using the same container when they share the same access control rules).

Note: Some Container IDs have the same access condition in use (Get Data) but may have a different access condition, not indicated in this specification, in update or create (Put Data or Load Key).

A.7 Data Types and Their Representation As for PIV, the ACIS card application uses references for keys, algorithms and cryptographic mechanism identifiers. The ACIS card specification version 1 uses the same command set as PIV and also uses the same status words returned by card commands after their execution. The ACIS card application and PIV card application use the same identifiers for the keys, algorithms and status words.

A.8 ACIS Data Model The ACIS data model is very similar to the PIV data model. As mentioned in the previous sections, some data objects do not have the same access control rules (or presence requirement) between PIV and ACIS but they have the same content except for two data objects described below:

Card Authentication Certificate Container The Certificate Card Authentication container (container ID = 0x0500, TAG 05FC101) is identical to PIV when it contains an X.509 certificate (when the key is an asymmetric Key) but contains a different set of data when the key is a symmetric key.

Card Authentication Certificate (symmetric key) Container ID: 0x0500, Always read

Data element Tag Type Information Max Bytes

Key Information 0x78 Fixed

Algorithm identifier (SP 800-78) 1 byte Key length in bits 2 bytes Key version 1 byte

4

Error Detection Code 0xFE LRC 0


February 27, 2008

Page A-8

Printed Information Buffer The Printed Information buffer has the same coding as PIV but the areas printed on the card have slightly different naming than PIV. The data element names shown is the following table indicate the ACIS printed area corresponding to the printed information buffer.

Printed Information Container ID: 0x3001, PIN

Data Element (TLV) Tag Type Max. Bytes*

Name (zone 2f) 0x01 Fixed Text 32 Employee Affiliation (zone 10f) 0x02 Fixed Text 20 ACIS/SIDA access level (zone 15f) 0x03 Fixed Text 20 Expiration date (zone 14f) 0x04 Fixed Text 9 Credential Serial Number (zone 1b) 0x05 Fixed Text 10 Issuer Identification (zone 2b) 0x06 Fixed Text 15 Issuer specific text (zone 4f) (Optional) 0x07 Fixed Text 20 Issuer specific text (zone 9b) (Optional) 0x08 Fixed Text 20 Error Detection Code 0xFE LRC 0


February 27, 2008

Page B-1

Appendix B - ACIS Card Application Command Interface The ACIS card application uses the same command interface as in PIV. Nevertheless, as the ACIS card application identifier is different from PIV some minor differences are inevitable. These differences are noted below.

B.1 Select Card Command The application to select is ACIS and the first 9 bytes of the AID are:

A0 00 00 03 68 20 00 00 02

In the response to the select command, the application property template provides the complete AID of the ACIS application selected (Tag 0x4F) along with the coexistent allocation tag authority which is PIV (as ACIS uses the application data object tags allocated by PIV) in tag 0x79 which contains the PIV application Registered Identifier of PIV. The other information returned in the application property template is similar to PIV for tags 0x50 and 0x5F50 which are both optional. The Application property template may be used to return the tags 0x53 (elementary) or 0x73 (constructed) when the ACIS card application has information to provide. In version 1 of this specification, no proprietary application information is defined and if such a data object is to be returned it should have a length of zero and no value field (0x5300 or 0x73025300).

B.2 Other Card Commands The other ACIS card commands are identical to the PIV card command interfaces and carry the same format in the response to the Get Data for backward compatibility reasons as well as the same format in the command data field for the Put Data.


February 27, 2008

Page C-1

Appendix C - ACIS Privilege Application The ACIS Privilege Application functions are not available in the ACIS card application Version 1 proposed for the ACIS Phase I deployment. This Appendix describes the ACIS privilege functions at a high level and is not intended to be detailed enough to allow an implementation. However, the knowledge of this planned capability may guide the ACIS implementers toward designing their initial solution with the ACIS card application Version 1 that can effectively utilize the second version when it becomes available. The object of the ACIS Privilege functions is to allow the ACIS card to adapt its response, when used in a local access control environment, based on the specific PACS checking for the existence of an access privilege in the card. In use, the PACS first informs the ACIS privilege card of its identity (PACS identifier provided to the card) and based on this knowledge, the ACIS card is able to provide a privilege number (equivalent of a specific PACS assigned FASC-N) known by this specific PACS. In addition, when this PACS was registered in the card, after the initial selection mechanism is successful, they both can enter into a mutual authentication process and establish a session key before any personally identifiable information is exchanged. The ACIS privilege application adds two new functions to the ACIS identity card application. These functions are described below.

C.1 ACIS Privilege PACS Registration The first function consists of registering a PACS (and its related information) in the ACIS card application at the time the ACIS card is registered in a PACS. The information consists in a PACS number/identifier, the number under which this PACS will recognize this ACIS card, the authentication mechanism used for mutual authentication and the key the ACIS card has to use for this mutual authentication. Because the card is identified by the PACS using a unique card identifier, the key allocated by the PACS can be unique (diversified) for each ACIS card. The PACS, identified uniquely in the ACIS name space (e.g. Airport code {Organization Identifier} || PACS code {System Code}), creates a secure message for the ACIS card to register the PACS entry. (This is similar to allowing a different FASC-N to be registered in the card for each airport/PACS allowing the card to be used as an access control badge.) This message needs to have all the authorizations from the card issuer (either by delegation or by request) to be recognized by the ACIS card as a legitimate message to modify its memory. The message sent to the card uses encryption and authentication to provide confidentiality of the diversified PACS key loaded in the card as well as certification of message origin in order for the card to honor the message. Upon reception of the PACS secure message, the card verifies it came from an authority it recognizes, and enters (into an internally managed PACS access control table) the PACS identifier along with the information required to later operate with this specific PACS (diversified key for mutual authentication and local access privilege credential number assigned to this card) . This message may be created during an interactive session between the ACIS card, the ACIS Identity Authority and the ACIS Access Control Authority (e.g. secure messaging and Global Platform) but could also be built based on an asynchronous secure message (e.g. secure e-mail) prepared in advance by the card issuer and sent to the card.


February 27, 2008

Page C-2

It is also possible for the ACIS Participant, using the appropriate command, to remove an existing PACS entry from the PACS access control table in a card issued to that ACIS Participant.

C.2 ACIS Privilege PACS Use When an ACIS card application version 2 is presented to a PACS, the following high level exchange will happen between the ACIS card and the PACS terminal (e.g. smart card reader located at the PACS-controlled point of access):

PACS Terminal Direction of Exchange ACIS Card Comments

ACIS card presented to a PACS terminal

Presentation by cardholder

PACS identifies itself to the ACIS card presented and sends a random number

Card searches its PACS access control table for the PACS identifier

If the PACS is not known a response is provided anyway preventing a rogue terminal from exploring the existing entries of the card’s access control table

Card sends back a random number and the ciphered card identifier under which this PACS knows this card

This card identifier may be different for each PACS and is ciphered using the mutual authentication key for this PACS

PACS deciphers the card identifier and establishes a session key

The card recognizes the session key establishment

This allows encrypted exchange of information (including PII) between the card and the PACS terminal with knowledge that the other entity is trusted

This process allows each PACS to control its own domain, have its own numbering scheme for cards and use its own keys which it do not have to be shared with any other systems. It therefore allows using symmetric algorithms for the mutual authentication process. This provides a fast mutual trust, a simple way to establish a session key, and protects the privacy of the user information when exchanged, protecting also against rogue terminals trying to abuse the user’s confidence in releasing PII protected only by the user’s PIN. In case a PACS key needs to be changed, the ACIS cards registered by this PACS as privilege cards need to be updated. The PACS may change its key without having the cards available. The cards will simply not work unless the old key is maintained by the PACS for a period of time. The simplest way to update the cards is to re-register the cards in that PACS. There is no need to re-issue the cards, update software in the cards or even revoke the cards at any point in time. It just means the old cards have an obsolete diversified key for this PACS in their memory and will no longer work with this PACS. When the PACS mutual authentication information is provided to the card upon registration, it is also possible to provide a PACS key number allowing the PACS to have rolling keys and limit the time during which a specific key is used. If key numbering is used, the card will have to


February 27, 2008

Page C-3

indicate the key number it uses when the card responds to the PACS in the mutual authentication exchange. Using asynchronous secure messages for the PACS and card registration (PACS access table update in the card) may require development of an application specific mechanism for secure exchange and update but has many benefits as it allows the PACS to prepare messages for known cards even when the cards are not physically present. Since the card has public keys and public key cryptographic capabilities, the development of such a protocol should not be difficult. This mechanism would allow an authority to plan ahead for a new access privilege request and work with a given PACS to prepare a message in advance, made available when a given ACIS Identity Card is presented to the PACS. This provides a convenient mechanism for use in secure access control systems when a request for granting of access privileges is required in advance.


February 27, 2008

Page D-1

Appendix D - ACIS Visual Card Topography The following section contains information related to the physical topography of the ACIS Card. This section applies to Aircraft Operator issued badge topography and is not required for ACIS Airport Operator badges or non-ACIS local access control badges. The intent of this specification is to standardize Aircraft Operator badge topography in a manner that is visually distinct from a typical Aircraft Operator badge. Acceptance of this badge topography for SIDA access of transient Aircraft Operator personnel is subject to the approval of Airport Operators under their Airport Security Program. Use of this topography as a standard badge for SIDA access by transient personnel may require changes to SIDA rules. The information on an ACIS Card will be available in visually printed form and electronic form. This section covers the placement of visual printed information on the physical ACIS card. It does not cover information stored in electronic form, such as stored data elements, and other possible machine-readable technologies.

• The ACIS version 1 card topography shall support use of a contact ICC interface. • The ACSI version 2 card topography shall use of a contact and a contactless ICC interface.

Note: This specification assumes a single chip is used for both contact and contactless interfaces relevant to ACIS card functionalities. This specification does not consider cards with additional technologies (e.g. proximity) which may create constraints of their own but should not in any way change or impact this specification.

• The ACIS Card shall contain mandated and optional machine-readable technologies. Note: Mandated and optional items (when used) shall be placed as described and depicted.

• Printed data shall not interfere with machine-readable technology. Note: Areas that are marked as reserved should not be used for printing without checking first with the manufacturer of the card. The reason for the recommended reserved areas is that placement of embedded contactless ICC modules may vary from manufacturer to manufacturer, as do constraints that may prohibit printing over the embedded contactless module. The ACIS Card topography provides flexibility for placement of such embedded module, either in the upper right-hand corner or in the lower bottom portion. Printing restrictions apply only to the area where the embedded module is located (i.e., upper right-hand corner, lower bottom portion). Note: Because technological developments may obviate the need to have a restricted area, or change the size of the restricted area, ACIS card issuers are encouraged to work closely with card vendors and manufacturers to ensure current printing procedures and methods are applied as well as potential integration of features that may improve tamper resistance and anti-counterfeiting of the ACIS card.

D.1 Mandatory Items on the Front of the ACIS Card • Zone 1f—Photograph. The photograph shall be placed in the upper left corner and be a full frontal

pose from top of the head to shoulder, as depicted in figure D-1. A minimum of 300 dots per inch (dpi) resolution shall be used. The background should follow recommendations set forth in SP 800-76.

• Zone 2f—Name. The full name shall be printed directly under the photograph in capital letters. The font shall be a minimum of 10 point.

• Zone 8f—Employee category. A printed employee category shall be printed on the card.


February 27, 2008

Page D-2

Note: Employee category includes categories such as “CREW”, “BAGGAGE HANDLER”, “GATE AGENT”, and other categories defined by the Aircraft Operator (Identity Authority). There is a need for this list to be defined and agreed upon by ACIS stakeholders. It also should be allowed to use this zone for categories which are not part of the basic agreed categories (for example using a different Zone 8f background color).

• Zone 9f— Header. The text “ACIS Credential” shall be placed as depicted in figure D-1. • Zone 10f— Sponsor/Employer. The sponsor/employer name shall be printed as depicted in figure

D-1. • Zone 14f—Expiration Date. The card expiration date shall be printed in a YYYYMMMDD format.

The Year, Month and Day may be separated from each other by a special character or a space. • Zone 15f— ACIS/SIDA Access Level. For ACIS Aircraft Operator badges which do not have any

specific SIDA airport coding, this zone should indicate the badge is not an Airport Operator Issued SIDA badge and contain the symbol indicated in figure D-1.

Color Photograph

Zone 1f - Photograph

ACIS CredentialZone 9f – Header

Category 6pt Bold

Zone 8f – Employee Category

Zone 15f – ACIS Access Level

Zone 16f – Photo border

Last NameFirst Name, Middle Initial

Zone 2f - Name

Dashed areas are subject to possible card manufacturer

printing restrictions

Issuer / Sponsor 6pt Bold

Zone 10f –Sponsor/Employer

Expiration DateIssuance Date Zone 13f – Issuance date

Footer AreaZone 12f - Footer

Zone 7f – Contacts

Zone 14f – Expiration date

Dashed areas are available for optional zones• 3f Signature• 4f Issuer specific text• 6f PDF

Zone 11f – Issuer logo

Blue = MandatoryGreen = Optional

NO

SIDA

Appendix Figure D-1 ACIS Card Front

D.2 Mandatory Items on the Back of the Card • Zone 1b—Identity Issuer assigned Credential Serial Number. This item shall be printed as depicted

in the back card figure and contain the unique serial number from the issuing entity. The format shall be at the discretion of the issuing department or agency.

• Zone 2b—Issuer Identification. This item shall be printed as depicted in the back card figure and consist of issuing Identity Authority code followed by the local site code (in case the issuing


February 27, 2008

Page D-3

Identity Authority has multiple issuing facilities). This number is used to contact the card issuer when a card is found or has stopped to function electronically. It is suggested to use, as in FIPS 201-1, a six character code for the issuing authority and a four character code for the issuing site. Because ACIS issuing authorities are identified using the Organization Identifier in the CHUID, the first six characters are printed as follow: Two first characters are the representation of the two hexadecimal digits of the Organization Identifier, followed by the three IATA codes of the issuing Identity Authority, followed by a dash in the six character. The four following characters are the issuing site number (if the identity authority has multiple issuing sites) or four zeros.

Back of Contact

Chip

Zone 3b – Magnetic Stripe

Zone 10b – Issuer SpecificOr

Zone 4b – “Return to”& Zone 5 – Physical Characteristics of Cardholder

Zone 8b – Linear Bar Code

Zone 9b Issuer Specific TextOr

Zone 6b – Emergency Responders& Zone 7b – Warning Language

Exact measurement for the various zones can be found in FIPS PUB 201-1 section 4.1 Physical PIV Card Topology

Zone 2b – Issuer Identification Number

Zone 1b – Serial Number

Appendix Figure D-2 ACIS Card Back

D.3 Optional items on the Front of the ACIS Card This section contains a description of the optional information and machine-readable technologies that may be used and their respective placement. The storage capacity of all optional technologies is as prescribed by individual ACIS card issuers and is not addressed in this standard. Although the items discussed in this section are optional, if used they shall be placed on the card as indicated.

• Zone 3f—Signature. If used, the issuing authority shall place the cardholder signature below the photograph and cardholder name as depicted in the figure. The space for the signature shall not


February 27, 2008

Page D-4

interfere with the contact and contactless placement. Because of card topography space constraints, placement of a signature may limit the size of the optional two-dimensional bar code.

• Zone 4f—Issuer Specific Text. If used, this area can be used for printing issuer/sponsor specific requirements, such as employee status.

• Zone 6f—Portable Data File (PDF) Two-Dimensional Bar Code. If used, the PDF bar code placement shall be on the left side of the card). If Zone f3 (cardholder signature) is used, the size of the PDF bar code may be affected. The card issuer should confirm that a PDF used in conjunction with an ACIS Card containing a cardholder signature will satisfy the anticipated PDF data storage requirements.

• Zone 11f—Issuer Logo. If used, the seal selected by the issuing/sponsor organization shall be printed in the area depicted in Figure D-1 (red dashed box). It shall be printed using the guidelines provided in the figure to ensure information printed on the Logo seal is legible and clearly visible.

• Zone 12f—Footer. The footer is the preferred location for ACIS Emergency Response Official Identification label. If used, an issuer may print “ACIS Emergency Response Official” as depicted in the figure, preferably in red text. ACIS card issuers may also print a secondary line in Zone 4f to further identify the ACIS emergency respondent’s role. Some examples of official roles are “Medical Personal”, “Firefighter” or “Emergency Response Team (ERT)”.

• Zone 13f—Issuance Date. If used, the card issuance date shall be printed above the expiration date in YYYYMMMDD format as depicted in the figure. Separators between the year, month day are allowed.

• Zone 16f—Photo Border. A border may be used with the photo to further identify employee category, as depicted in the figure.

D.4 Optional Items on the Back of the Card • Zone 3b—Magnetic Stripe. If used, the magnetic stripe shall be high coercivity and placed in

accordance with ISO 7811, as illustrated in Figure D-2. • Zone 4b—Return To. If used, the “return if lost” language shall be generally placed on the back of

the card as depicted in Figure D-2. • Zone 5b—Physical Characteristics of Cardholder. If used, the cardholder physical characteristics

(e.g., height, eye color, hair color) shall be printed in the general area illustrated in Figure D-2. • Zone 6b—Additional Language for ACIS Emergency Responder Officials. ACIS card issuers may

choose to provide additional information to identify emergency response officials or to better identify the cardholder’s authorized access. If used, this additional text shall be in the general area depicted and shall not interfere with other printed text or machine-readable components.

• Zone 7b—Warning Language. If used, standard Section 499, Title 18, language warning against counterfeiting, altering, or misusing the card shall be printed in the general area depicted in Figure D-2.

• Zone 8b—Linear Bar Code. If used, a linear 3-of-9 bar code shall be generally placed as depicted in Figure D-2. It shall be in accordance with Association for Automatic Identification and Mobility (AIM) standards. Beginning and end points of the bar code will be dependent on the embedded contactless module selected. ACIS card issuers are encouraged to coordinate placement of the bar code with the card vendor.


February 27, 2008

Page D-5

• Zone 9b—Issuer/Sponsor-Specific Text. In cases other defined optional elements are not used, Zone 9 may be used for other issuer or sponsor specific information, as depicted in Figure D-2. For example, emergency responder officials may use this area to provide additional details.

• Zone 10b—Issuer Specific Text. Zone 10 is similar to Zone 9 in that it is another area for providing issuer or sponsor specific information.


February 27, 2008

Page E-1

Appendix E - ACIS Physical and Electrical Card Characteristics

E.1 ACIS Physical Characteristics Printed Material

• The printed material shall not rub off during the life of the ACIS Card, nor shall the printing process deposit debris on the printer rollers during printing and laminating.

• Printed material shall not interfere with the contact and contactless ICC(s) and related components, nor shall it obstruct access to machine-readable information.

Tamper Proofing and Resistance • The ACIS Card shall contain security features that aid in reducing counterfeiting, are resistant to

tampering, and provide visual evidence of tampering attempts. At a minimum, an ACIS Card shall incorporate one such security feature. Note: Examples of these security features include optical varying structures, optical varying inks, laser etching and engraving, holograms, holographic images and watermarks.

• Incorporation of security features shall be in accordance with durability requirements ISO/IEC 7810.

• Incorporation of security features shall be free of defects, such as fading and discoloration. • Incorporation of security features shall not obscure printed information. • Incorporation of security features shall not impede access to machine-readable information.

Physical Characteristics and Durability • The ACIS Card Phase I shall contain a contact ICC interface. • The ACIS card Phase III shall contain a contact and a contactless ICC interface. • The card body structure shall consist of card material(s) that satisfy the card characteristics in

ISO/IEC 7810 and test methods in American National Standards Institute (ANSI) 322. • The card shall be 27- to 33-mil thick (before lamination) in accordance with ISO/IEC 7810. • The ACIS Card shall not be embossed. • The card printed information shall not be obscured if decals are used on the card. • ACIS card issuers may choose to punch an opening in the card body to enable the card to be worn

on a lanyard. ACIS card issuers shall ensure such alterations will not damage or interfere with machine-readable technology, such as the embedded antenna used by the contactless interface.

E.2 ACIS Integrated Circuit Card (ICC) Requirements Conformance to Standards

• The ACIS ICC contact interface shall operate in a manner compatible with ISO/IEC 7816 Parts 1, 2, and 3.

• The ACIS ICC contactless interface shall operate in a manner compatible with ISO/IEC 14443 Parts 1, 2, and 3.

• The ACIS ICC shall be testable using test methods defined in ISO/IEC 10373.


February 27, 2008

Page E-2

• The ACIS ICC shall support cryptographic functions interoperable with FIPS 201 identification authentication protocols.

Microcontroller • The ACIS ICC shall provide non-volatile memory of a size not smaller than 64K bytes. • The ACIS ICC shall be resistant to electro-static discharge events occurring during normal usage.

Cryptographic Capabilities • The ACIS ICC shall support a TSA specified list of symmetric key cryptographic algorithms to

include two-key Triple DES. • The ACIS ICC shall support a TSA specified list of asymmetric key cryptographic algorithms to

include RSA 2048 bit. • The ACIS ICC shall support a TSA specified list of message digest algorithms to include SHA-256. • The ACIS ICC shall support a TSA specified list of key exchange methods. • The ACIS ICC shall support a TSA specified list of signature algorithms compatible with FIPS PUB

186. • The ACIS ICC shall support onboard key generation with a performance requirement to generate

RSA 2048 key pairs in under 30 seconds.

Security • The ACIS ICC shall be certified as a FIPS 140-2 Level 2 cryptographic module. • The ACIS ICC shall support countermeasures to Simple Power Analysis tampering. • The ACIS ICC shall support countermeasures to Differential Power Analysis tampering.


February 27, 2008

Page F-1

Appendix F - ACIS Applicant Enrollment Data ACIS Applicant Enrollment Data is based upon Enrollment data used in the TWIC Program. Specific data element definitions are extracts for the TSA Screening Gateway Specification, SG-DEV-SPEC-ACIS-V1_0D, 08/01/07, Draft version.

F.1 Application Element The Applicant element contains several attributes that define the applicant’s profile. The element’s component specifications are included in the following table.

Field Name Field Type

Description Data Type

Min. Length

Max. Length

Format/Value

ProgTransactionID Attribute Interfacing-enrollment-system’s unique Transaction ID.

String 1 128

AppType Attribute Pre-defined value for application type.

String Enum. Min.

Enum. Max.

Enroll Update Delete

FullNameList Element List of “Full Name” elements.

- - -

PersonalInformation Element “PersonalInformation” elements.

- - -

TelephoneNumberList Element List of “TelephoneNumber” elements.

- - -

EmailAddressList Element List of “EmailAddress” elements.

- - -

CitizenshipList Element List of “Citizenship” elements.

- - -

AlienRegistrationNumber Element USCIS issued unique Alien Registration Number.

String 8 10 (A/a)?\d{8,9} Example: A12345678 A123456789 a12345678 a123456789

VisaList Element List of “Visa” elements.

- - -

AddressList Element List of “Address” elements.

- - -

EmployerList Element List of “Employer” elements.

- - -

BadgeList Element List of “Badge” elements.

- - -


February 27, 2008

Page F-2



Min. Length

Max. Length

Format/Value

BiometricImageList Element List of ”BiometricImage” elements.

- - -

DocumentImageList Element List of ”DocumentImage” elements.

- - -

F.2 FullNameList Element The FullNameList element may contain multiple FullName elements that contain definition of the applicant’s names. The element’s component specifications are included in the following table.



Min. Length

Max. Length

Format/Value

FullName Element 1 of n full applicant names.

- - -

Full Name Element The FullName element may contain multiple subordinate elements that define the applicant’s names.



Min. Length

Max. Length

Format/Value

NameType Attribute Pre-defined value representing type of name.

String Min. Enum.

Max. Enum.

P = Primary A = Alias

LastName Element Last name of applicant

String 2 40

FirstName Element First name of applicant

String 0 40

MiddleName Element Middle name of applicant

String 0 40

Generation Element Generation suffix of applicant name

String Min. Enum.

Max. Enum.

JR = Junior SR = Senior I = First II = Second III = Third IV = Forth V = Fifth VI = Sixth VII = Seventh VIII = Eighth IX = Ninth


February 27, 2008

Page F-3

F.3 PersonalInformation Element The PersonalInformation element contains an applicant’s personal information. The element’s component specifications are included in the following table.



Min. Length

Max. Length

Format/Value

Gender Element Pre-defined value representing an applicant’s gender.

String 1 1 M = Male F = Female U = Unknown

DOB Element Date of birth String 8 10 YYYYMMDD YYYY-MM-DD YYYY/MM/DD

Height Element Applicant’s height in feet and inches

String 1 3 Format is a compound 3-digit integer of the form: XYY

Where: X = “feet” YY = inches

Weight Element Applicant’s weight in pounds.

String 1 3 Format is a 3-digit integer, representing pounds: XXX

EyeColor Element Applicant’s eye color

String 3 3

HairColor Element Applicant’s hair color.

String 3 3

PlaceofBirth Element Applicant’s place of birth

- - - -

SSN Element Applicant’s Social Security Number

String 9 11 XXXXXXXX XXX-XX-XXXX

PlaceOfBirth Element The element’s component specifications are included in the following table.



Min. Length

Max. Length

Format/Value

City Element Applicant’s birth city

String 1 64 -

County Element Applicant’s birth county

String 1 64 -


February 27, 2008

Page F-4



Min. Length

Max. Length

Format/Value

State Element Applicants birth state (2 character US State Code)

String 2 3

Country Element Applicant’s birth country

String Min. Enum.

Max. Enum.

TelephoneNumberList Element The TelephoneNumberList element may contain multiple TelephoneNumber elements that contain an applicant’s telephone numbers. The element’s component specifications are included in the following table.



Min. Length

Max. Length

Format/Value

TelephoneNumber Element Value of telephone number

String 10 15 XXX-XXX-XXXX XXXXXXXXXX

TelephoneNumber Element The TelephoneNumber element may contain multiple subordinate attributes/elements that contain an applicant’s telephone numbers.



Min. Length

Max. Length

Format/Value

PhoneType Attribute Pre-defined code that represents type of telephone

String Min. Enum.

Max. Enum.

H – home B – Business M – Mobile P – Pager F – Fax

EmailAddressList Element The EmailAddressList element may contain multiple EmailAddress elements that identify the applicant’s e-mail addresses. The element’s component specifications are included in the following table.



Min. Length

Max. Length

Format/Value

EmailAddress Element 1 of n e-mail addresses

String- 6 100 -


February 27, 2008

Page F-5

EmailAddress Element The EmailAddress element may contain multiple subordinate attributes/elements that contain an applicant’s e-mail addresses.



Min. Length

Max. Length

Format/Value

EmailAddressType Attribute Type of e-mail address

String Min. Enum.

Max. Enum.

P – Primary S – Secondary

CitizenshipList Element The CitizenshipList element may contain multiple Citizenship elements that contain an applicant’s citizenship information. The element’s component specifications are included in the following table.



Min. Length

Max. Length

Format/Value

Citizenship Element 1 of n citizenship elements

- - - -

Citizenship Element The Citizenship element may contain multiple subordinate elements that contain an applicant’s citizenship identification.



Min. Length

Max. Length

Format/Value

Country Element Identification of the country of citizenship

String Min. Enum.

Max. Enum.

NaturalizationDate Element Identification of the citizenship naturalization date

String 8 10 YYYYMMDD YYYY-MM-DD YYYY/MM/DD

PassportList Element Contains one or more Passport elements

- - - -

PassportList Element The PassportList element may contain multiple Passport elements that contain an applicant’s citizenship identification.


February 27, 2008

Page F-6



Min. Length

Max. Length

Format/Value

Passport Element 1 of n passport elements

- - - -

PassportElement The Passport element may contain multiple subordinate attribute/elements that contain an applicant’s passport information.



Min. Length

Max. Length

Format/Value

PassportType Attribute Pre-defined value indicating passport type

String Min. Enum.

Max. Enum.

P – personal M – military D – diplomatic

PassportNumber Element Applicant’s passport number

String 1 20 -

PassportCountry Element Identification of passport country

String Min. Enum.

Max. Enum.

VisaList Element The VisaList element may contain multiple Visa elements that contain an applicant’s Visa information. The element’s component specifications are included in the following table.



Min. Length

Max. Length

Format/Value

Visa Element Contains Visa information

- - - -

VisaElement The Citizenship element may contain multiple subordinate elements that contain an applicant’s citizenship identification.



Min. Length

Max. Length

Format/Value

VisaType Attribute Visa Type String 1 20 - VisaNumber Element Unique Visa

Number String 1 20 -


February 27, 2008

Page F-7

AddressList Element The AddressList element may contain multiple Address elements that contain an applicant’s address information. The element’s component specifications are included in the following table.



Min. Length

Max. Length

Format/Value

Address Element Contains StreetAddress1, StreetAddress2, City, State, PostalCode, Country If Country is US then State must be from USPS standard list of state abbreviations; if Country is not US then State is ignored.

- - - -

Address Element The Address element may contain multiple subordinate elements that contain an applicant’s address information.



Min. Length

Max. Length

Format/Value

AddressType Attribute Pre-defined value indicating an applicants address type

String Min. Enum.

Max. Enum.

M – mailing R – residential

HistoricalPosition Attribute Required Attribute of Address Numeric – ascending integer sequence associated with the most recent to oldest address

Integer 1 1 -

StreetAddress1 Element First line of street address

String 1 128 -

StreetAddress2 Element Second line of street address

String 1 128 -

City Element Identification of City

String 1 64 -


February 27, 2008

Page F-8



Min. Length

Max. Length

Format/Value

State Element Identification of State

String 2 3

PostalCode Element Address postal code

String 5 10

Country Element Identification of country

String Min. Enum.

Max. Enum.

EmployerList Element The EmployerList element may contain multiple Employer elements that contain an applicant’s employer information. The element’s component specifications are included in the following table.



Min. Length

Max. Length

Format/Value

Employer Element Identifies and applicant’s employer information.

- - - -

Employer Element The Employer element may contain multiple subordinate elements that contain an applicant’s employer information.



Min. Length

Max. Length

Format/Value

HistoricalPosition Attribute Attribute of Employer Numeric sequence of Employer

Integer 1 1 -

EmployerName Element Alphanumeric String 1 128 - EmployerAddress Element Contains

StreetAddress1, StreetAddress2, City, State, PostalCode, Country

- - - -

TelephoneNumber Element Alphanumeric String 10 15 XXX-XXX-XXXX XXXXXXXXXX


February 27, 2008

Page F-9

EmployerAddress Element The EmployerAddress element may contain multiple subordinate elements that contain an employer’s address information.



Min. Length

Max. Length

Format/Value

StreetAddress1 Element First line of employer street address

String 1 128 -

StreetAddress2 Element Second line of employer street address

String 1 128 -

City Element Employer address city

String 1 64 -

State Element Employer address state

String 2 3

PostalCode Element Employer address postal code

String 5 10

Country Element Employer address country

String Min. Enum.

Max. Enum.

BadgeList Element The BadgeList element may contain multiple Badge elements that describe an applicant’s badges. The element’s component specifications are included in the following table.



Min. Length

Max. Length

Format/Value

Badge Element 1 of n badges - - - -

Badge Element The Badge element may contain multiple subordinate elements that contain an applicant’s badge information.



Min. Length

Max. Length

Format/Value

BadgeNumber Element Badge identification number

String 1 20 -

LocalBadgeType Element Local badge type String 1 50 - AccessLevelList Element List of access

levels associated with an applicant’s badge

- - - -


February 27, 2008

Page F-10



Min. Length

Max. Length

Format/Value

BadgeStatus Element Status of the applicant’s badge

String Min. Enum.

Max. Enum.

A = Active NI = Not Issued P = Pending R = Revoked S = Suspended

AccessLevelList Element The AccessLevelList element may contain multiple AccessLevel elements that describe an applicant’s badge access levels.



Min. Length

Max. Length

Format/Value

AccessLevel Element Identifies associated badge access level

String Min. Enum.

Max. Enum.

SIDA Sterile Area AOA Secured Area Public Area

BiometricImageList Element The BiometricImageList element may contain multiple BiometricImage elements that contain an applicant’s biometric identifiers. The element’s component specifications are included in the following table.



Min. Length

Max. Length

Format/Value

BiometricImage Element 1 of n biometrics submitted

- - - -

BiometricImage Element The BiometricImage element may contain multiple subordinate elements that contain an applicant’s biometric identifiers.



Min. Length

Max. Length

Format/Value

ImageType Attribute Pre-defined values representing biometric image type

String Min. Enum.

Max. Enum.

EFTS IrisLeft IrisRight Facial Image


February 27, 2008

Page F-11



Min. Length

Max. Length

Format/Value

ObjectPayload Element The Base64 encoded biometric image

Base64Binary

1 NTE 2 MB -

DocumentImageList Element The DocumentImageList element may contain multiple DocumentImage elements that contain an applicant’s identification documents. The element’s component specifications are included in the following table.



Min. Length

Max. Length

Format/Value

DocumentImage Element 1 of n documents submitted

- - - -

DocumentImage Element The DocumentImage element may contain multiple subordinate elements that contain an applicant’s identification document information.



Min. Length

Max. Length

Format/Value

DocType Attribute Pre-defined value representing document type

String 1 128 -

DocFormat Attribute Pre-defined value representing document format

String Min. Enum.

Max. Enum.

PDF JPEG

ObjectPayload Element The Base64 encoded document image

Base64Binary

1 NTE 2 MB -

aviation credential interoperability solution (acis) technical

Documents