> For the complete documentation index, see [llms.txt](https://docs.verifone.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verifone.com/kld/kld-user-guide/user-guide-p400/key-concepts.md). # Key Concepts ### How Keys are created or Imported into KLD * Master Session and DUKPT-Initial Keys can only be imported through files (via USB thumb drive). * DUKPT-BDK and Fixed keys can be created through UI as Key components or they can also be imported through files (via USB thumb drive). * The product UI has a menu option to import keys, described below in this document. ### KEK (Key Encryption Key) * When importing keys through files, the key data in these files is encrypted using a Key Encryption Key (KEK) * KEK must be created through UI using key components. The product UI has a menu option to create KEK(s), described below in this document. * This **KEK is known as KBPK (Key Block Protection Key) for TR-31 formatted key data and just as KEK for Cryptogram data format** ### Key List * A Key list contains (consists) a list of keys of a specific key type. * Key List Type can be "Master-Session" or "DUKPT-Initial" types. * A Master Session Key List can contain sub-category, "Master Session KEK" or "Master Session KBPK" * A DUKPT-Initial Key List can only contain "DUKPT Initial Keys" * A Key List cannot contain multiple Key Types. For example, it cannot contain both Master Session and DUKPT-Initial Keys. * A Key List can have many keys, thousands of keys. * The Key list Keys can be in multiple key files. * For example, if the requirement is to send 2 Master-Session KEK keys to each of the target terminals, then there will be 2 Master KEK files in this key list. * One key from each file (the top key) is sent to the terminal and thus 2 KEK keys are sent. * A Key List when imported uses a specific file structure on the USB. Refer to the "Key List Import" Section below. * One or more Key Lists are chosen when a reference set (see below) is created. * When loading the keys to a terminal, the first key (top key) from a key list file is sent to the terminal and deleted from that list. * A Key List can also have optional Terminal S/N (Serial Number). If there is one, those keys will be sent to that specific Terminal with that S/N. * Individual Keys cannot be selected or deleted from a Key List. A key list is created, selected and deleted as a whole. * Internally, the product will take one key at a time from the list and delete it automatically (after successfully sending to the terminal). * A key list can be replenished (refilled) through USB drive. Refer to the "Key List Import" Section below. * The product UI has a menu option to import key lists as described below in this document. * **The KLD memory is limited. We recommend not exceeding a total of about 10 to 15 thousand keys in total.** ### Difference between Keys and Key Lists * Keys are treated as individual keys, whereas a Key List is a collection of keys (or group of keys) of same Key Type as mentioned above in the "Key List" section. * The BDK and Fixed are keys treated as individual keys. Users can see, edit (only key name) and delete individual keys. These keys can be created through UI as Key components or can be imported through file on USB. * Through UI, user can create these keys one at a time. * Through File on USB, user can have more than one key in the file and each line in the file is one individual key (like entered through UI). * Master Session and Initial Keys are treated as key lists. A key list can have many keys (thousands of keys) and all are treated as single set (Key list). * Through UI, user can import these Key List file(s) on the USB. * Through UI, user can see the imported key list name, rename the key list name and delete the key list but cannot see or modify the individual keys inside the key list since there can be too many keys in a list to show on the UI. ### Key Block Header (KBH) * Every key that is sent to a terminal has a list of Key Attributes. The attributes are collectively known as Key Block Header (KBH) * User will be asked for these Key attributes for each Key (or a Key List) when they select keys or Keys Lists when creating a reference set * Key Attributes are * Key Algorithm * Key Usage - K0 (KEK), K1 (KBPK), M0 (MAC), D0 (Data), DUKPT etc. * Key usage "K1" is not currently supported in Trinity Platform. * The KLD does not prevent the user from sending the key with "K1" usage to Trinity platform. It will fail or the terminal will ignore it. * The reason to allow this is, in future, KLD software does not require a change when the terminal starts supporting "K1" keys * Mode - Encrypt, Decrypt, Verify, etc. * Slot Number - for Trinity Platform, Keys go into a slot. The number ranges from 1 to 9999. The payment application will refer to a key by this slot number and an engine type (hard coded internally) to load/use the key. * Terminal Key Name - for Neo and Victa Platforms, a Key is referenced on the terminal by a name. The payment application will refer to a key by this name to load/use the key. * For a key list there is only one KBH for that list. It applies to all the keys in that list since all the keys in a given Key List file must be of same key algorithm. * For individual keys like DUKPT BDK or Fixed keys, the KBH is per key * The product UI has a menu option to create KBH, described below in this document. ### Reference Set * All the Verifone payment terminals have a specific OS platform. * Currently this Verifone KLD product supports terminals that fall under 3 specific platforms, namely, Trinity, Neo and Victa * The KLD stores a collection of keys created by user through UI or by importing keys from files through USB thumb drive. * A reference set points (refers) to a subset of keys from the above key collection to be sent to a specific target terminal platform. Or it is a snapshot of the keys to be sent to terminal belonging to a specific platform. * When a reference set is created, one of the three platforms is chosen, and one or more keys or key lists are chosen. This reference set can only be used for that specific platform to upload keys to the terminal. * More than one reference set can point to the same keys or key lists * Use can choose a specific reference set to upload key to the terminal. The user can also set default reference set that will be automatically used when uploading keys to the terminal. * The product UI has a menu option to create one or more reference sets as described below in this document. ### Limited Editing of the Data on the KLD * The product does not have many editing features for a reason. * When a key is created through UI or imported via file, only Key name can be edited. Obviously, we cannot edit the key value or the algorithm. That leaves just the key name or Key list name editable. * When a CSR or Signer cert is created, nothing can be edited since there is no real data that can be edited. * While editing reference set is possible, currently it is not allowed. May be in Future. * Any of these data can be deleted and recreated. * We feel most of the KLD data is set up rarely (or infrequently) or just once, limited editing of this data should not be a concern. As mentioned, one can delete and re-create. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.verifone.com/kld/kld-user-guide/user-guide-p400/key-concepts.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.