ID TECH Key Injection Facility and Service

ID TECH is a certified KIF (Key Injection Facility). We currently have more than one hundred production keys. Every Key we manage has an ID TECH part number (i.g. IDT-KEYINJ-D01). If you need a unit injected with the specific key, an ID TECH salesperson will be able to tell you if the key is already managed by ID TECH or if the key will need to be transferred to ID TECH via a Secure Key Transfer process.

ID TECH has a service where we can create a new key. This service is referred to as a Key Generation service.

ID TECH also can accept new keys through key transfer. For key transfer, it can be done through the cryptogram transfer method or key component transfer method. The transfer procedure meets PCI security standards.  The cryptographic keys can be identified/validated by the KCV (Key Check Value).  

How to know with what key your reader is injected?

If you have a reader and you are not sure if it has been injected, you can look for the IDT-KEYINJ-xxx sticker on the reader. We can look up this key part number and tell you what it is.

You can also look at the KSN (Key Serial Number). This 10-byte hex number is always available in plain text with any encrypted data. If the KSN begins with 629949, then it is a key ID TECH created and very likely injected into your reader. You can let us know the KSN and we can share what can be learned from it. Also, we can look up the reader's sales history using the serial number on the reader. Often we can track down the sales invoice that may include a key injection service that specifies the key to be injected

Can the customer inject the encryption key by themselves?

Unless the product supports the RKI (Remote Key Injection), only a Certified Key Injection Facility can inject the encryption key.

What's the structure of a KSN?

A KSN is 10 bytes fixed. It starts with the 3 bytes(6 digits, e.g. 629949 for our Demo key) IIN (Issuer Identification Number), and the next byte(2 digits) is the Customer ID which is fixed too, the next byte(two digits) is the Group ID (varies), next 19 bits is the Device ID which is unique to each device and the last 21 bits is the counter which increases by 1 for every swipe. You can tell the key is different by the first few bytes of the KSN. 

Example:

KSN: 62994900750003c0000f (as highlighted in the screenshot attached below)
Where:
IIN: 629949
CID: 00
Group ID: 75
Device ID: 0000 0000 0000 0011 110 ( 19 bit in binary) This is from the hex code 00003c with the last bit of the "c" going to the Counter field
Counter: 0 0000 0000 0000 0000 1111 (21 bits in binary) This is the last bit of the hex "c" plus the hex "0000f"

Open

How to tell if the Augusta has an encryption key injected and how to activate the encryption with the key pre-injected?

Open

Can you show me how to decrypt the encrypted data or provide the decryption dll used by your Demo?

Search the Knowledge Base for several articles on how to perform decryption. Note: Encryption/Decryption with production keys happens within an HSM (hardware security module). You can perform decryption with a reader that was injected with a demo key instead of a production key.

Do you provide the key-generating service?

Yes. Please contact our Sales team.

Can SecuRED and SREDKey be remotely key injected?

No, as of now. 

Can I switch from AES to 3DES after the key injection has happened?

For some readers, you can... For example, many VivoPay readers allow for this. PCI-certified SRED devices and NGA readers like Augusta, Spectrum Pro, and MiniSmart II do not.

What's the key press sequence to put the SREDKey into the KeyInjection mode?

" # Cancel  BS  Cancel  Enter  #" within 5 seconds after the device powered up with Ready displayed (for SREDKey)

What's the key injection protocol and converter cable for Augusta?

Augusta takes the following settings (and needs the ID-80000001-007 converter cable note: rev C and higher are required for FutureX 6. x) 

• 9600 Baud

• 8 data bits

• N parity

The firmware version of your HSM will need to support IDTECH NGA protocol.  And LCL-KEK must be requested/transferred for the 3rd party key injection facilities to be able to inject our Augusta readers with production keys

What is LCL-KEK, KTK, and how an LCL-KEK can be securely transferred to a 3rd party KIF(Key Injection Facility)?

The LCL-KEK or Local Key Encryption Key is present in all current EVM readers. It is designed to prevent unauthorized key injection/modification. When performing key injection the HSM must validate the LCL-KEK. ie the reader's stored LCL-KEK will need to also exist on the injecting HSM system. A KTK or a Key Transport Key is used to protect a key while in transport. The KTK must get transferred to your HSM in multiple components first. However, once that's done, then we can send keys encrypted with the KTK. This is far simpler than spiting the key, and sending them to 2 different recipients via 2 different carriers.

For K100,  is there a way to check whether a unit has the Production LCL-KEK or the Demo LCL-KEK loaded? If yes, how to do so?

You can use the command "Get Key status"(78 46 25) to get the key status with the dotNET SDK Demo (aka uDemo).

Where can I find out the correct key injection cable and protocol for injecting an ID TECH product?

There is a document available to our partners. We will only share this information with a certified key injection facility.

What does a transferred key look like?

Here is a test key transfer key parts: 

Key Value: 95036100
KCV (entire Key): E45B50

Key Component: 1 of 2
Check Digit: 3218A6
Key Component: F2D53475FBAE1C3BDCFE9DDCBC23E96B

Key Component: 2 of 2
Check Digit: 8F9627
Key Component: 1AA1B5676BF243736B45DF9840B5A8B3

How does one split / combine cryptographic keys?

Related Articles: