IBM Crypto Education Community

I'm using CSNBKIM to import a DES key (double length) and when I run CSNBKYT (ENC-ZERO) the result changes as I change the key type even though the clear key value is the same. Can anyone explain the reason and if there is how I can generate the KCV without taking into account the type of key?



* KIM_KEY_TYPE..: MAC
* KIM_SOURCE_KEY: 00000000000000000000000000000000F87AFBF7A839878589E91D31B580E92D
* KIM_TARGET_KEY: 010000000000C000A6A478E2E97CE31A95DC4536FD3F90A6000000000000000000054D0003000000000000000000000000000000000000000000000027433ED8
* KYT_KCV.......: E954C35D00000000
-------------------------------------------------------------------------------

* KIM_KEY_TYPE..: DATA
* KIM_SOURCE_KEY: 00000000000000000000000000000000F87AFBF7A839878589E91D31B580E92D
* KIM_TARGET_KEY: 010000000100C000A6A478E2E97CE31AD0F6D06C711173ADF5BC2A2AFAD0CDA500000000000000000000000000000000000000000000000000000010C4B757F4
* KYT_KCV.......: 80F1F0E800000000
-------------------------------------------------------------------------------

* KIM_KEY_TYPE..: IPINENC
* KIM_SOURCE_KEY: 00000000000000000000000000000000F87AFBF7A839878589E91D31B580E92D
* KIM_TARGET_KEY: 010000000000C000A6A478E2E97CE31A70D41BBFFF8E26DD2E0996EF73248ABE00215F000341000000215F0003210000000000000000000000000000A9573E45
* KYT_KCV.......: FE456CCC00000000
-------------------------------------------------------------------------------


Renato Brito.

------------------------------
Renato Almeida de Brito
------------------------------

As written above, you are not importing clear key material. When you call KIM with a NULL token containing key material, that tells ICSF to treat the key material as already encrypted.

From Appendix B. Key token formats:

Null key tokens

With some callable services, a null key token can be used instead of an internal or an external key token.
A service generally accepts a null key token as a signal to use a key token with default values. A null key
token always has a value of X'00' as its first byte.

Null AES fixed-length key token
       A null AES key-token consisting of 64 bytes of X'00'.

Null DES fixed-length key token
       A null DES key-token consisting of 64 bytes of X'00'.

       The CSNBKIM callable service accepts input with offset zero valued to X'00'. In this special case, the
       service treats information that starts at offset 16 as an enciphered, single-length or double-length
       key.

What happens is that CSNBKIM will treat the single or double-length key material as it was already encrypted by the importer_key_identifier. Since all three key types have different control vectors, the actual key material that will be used will not be the same after import.

I think you want the CSNBSKM callable service for this.

------------------------------
Eric Rossman
------------------------------

Original Message:
Sent: Wed September 01, 2021 04:54 PM
From: Renato Almeida de Brito
Subject: Different KCV values for the same clear key value.

I'm using CSNBKIM to import a DES key (double length) and when I run CSNBKYT (ENC-ZERO) the result changes as I change the key type even though the clear key value is the same. Can anyone explain the reason and if there is how I can generate the KCV without taking into account the type of key?



* KIM_KEY_TYPE..: MAC
* KIM_SOURCE_KEY: 00000000000000000000000000000000F87AFBF7A839878589E91D31B580E92D
* KIM_TARGET_KEY: 010000000000C000A6A478E2E97CE31A95DC4536FD3F90A6000000000000000000054D0003000000000000000000000000000000000000000000000027433ED8
* KYT_KCV.......: E954C35D00000000
-------------------------------------------------------------------------------

* KIM_KEY_TYPE..: DATA
* KIM_SOURCE_KEY: 00000000000000000000000000000000F87AFBF7A839878589E91D31B580E92D
* KIM_TARGET_KEY: 010000000100C000A6A478E2E97CE31AD0F6D06C711173ADF5BC2A2AFAD0CDA500000000000000000000000000000000000000000000000000000010C4B757F4
* KYT_KCV.......: 80F1F0E800000000
-------------------------------------------------------------------------------

* KIM_KEY_TYPE..: IPINENC
* KIM_SOURCE_KEY: 00000000000000000000000000000000F87AFBF7A839878589E91D31B580E92D
* KIM_TARGET_KEY: 010000000000C000A6A478E2E97CE31A70D41BBFFF8E26DD2E0996EF73248ABE00215F000341000000215F0003210000000000000000000000000000A9573E45
* KYT_KCV.......: FE456CCC00000000
-------------------------------------------------------------------------------


Renato Brito.

------------------------------
Renato Almeida de Brito
------------------------------

Eric, thanks for your reply. The point is that the key I'm importing is encrypted by a KEK, so I'm using CSNBKIM. Can I use CSNBSKM to import a key encrypted by a KEK? The problem is that the type of this encrypted key is MAC and the KCV I'm getting from our partner only hits when I import the key as DATA. I would like to know if there is a way to not consider the Control Vector in CSNBKYT so that I don't need to "import" the key twice just to confirm the KCV value.

------------------------------
Renato Almeida de Brito
------------------------------

Original Message:
Sent: Wed September 01, 2021 05:29 PM
From: Eric Rossman
Subject: Different KCV values for the same clear key value.

As written above, you are not importing clear key material. When you call KIM with a NULL token containing key material, that tells ICSF to treat the key material as already encrypted.

From Appendix B. Key token formats:

Null key tokens

With some callable services, a null key token can be used instead of an internal or an external key token.
A service generally accepts a null key token as a signal to use a key token with default values. A null key
token always has a value of X'00' as its first byte.

Null AES fixed-length key token
       A null AES key-token consisting of 64 bytes of X'00'.

Null DES fixed-length key token
       A null DES key-token consisting of 64 bytes of X'00'.

       The CSNBKIM callable service accepts input with offset zero valued to X'00'. In this special case, the
       service treats information that starts at offset 16 as an enciphered, single-length or double-length
       key.

What happens is that CSNBKIM will treat the single or double-length key material as it was already encrypted by the importer_key_identifier. Since all three key types have different control vectors, the actual key material that will be used will not be the same after import.

I think you want the CSNBSKM callable service for this.

------------------------------
Eric Rossman

Original Message:
Sent: Wed September 01, 2021 04:54 PM
From: Renato Almeida de Brito
Subject: Different KCV values for the same clear key value.

I'm using CSNBKIM to import a DES key (double length) and when I run CSNBKYT (ENC-ZERO) the result changes as I change the key type even though the clear key value is the same. Can anyone explain the reason and if there is how I can generate the KCV without taking into account the type of key?



* KIM_KEY_TYPE..: MAC
* KIM_SOURCE_KEY: 00000000000000000000000000000000F87AFBF7A839878589E91D31B580E92D
* KIM_TARGET_KEY: 010000000000C000A6A478E2E97CE31A95DC4536FD3F90A6000000000000000000054D0003000000000000000000000000000000000000000000000027433ED8
* KYT_KCV.......: E954C35D00000000
-------------------------------------------------------------------------------

* KIM_KEY_TYPE..: DATA
* KIM_SOURCE_KEY: 00000000000000000000000000000000F87AFBF7A839878589E91D31B580E92D
* KIM_TARGET_KEY: 010000000100C000A6A478E2E97CE31AD0F6D06C711173ADF5BC2A2AFAD0CDA500000000000000000000000000000000000000000000000000000010C4B757F4
* KYT_KCV.......: 80F1F0E800000000
-------------------------------------------------------------------------------

* KIM_KEY_TYPE..: IPINENC
* KIM_SOURCE_KEY: 00000000000000000000000000000000F87AFBF7A839878589E91D31B580E92D
* KIM_TARGET_KEY: 010000000000C000A6A478E2E97CE31A70D41BBFFF8E26DD2E0996EF73248ABE00215F000341000000215F0003210000000000000000000000000000A9573E45
* KYT_KCV.......: FE456CCC00000000
-------------------------------------------------------------------------------


Renato Brito.

------------------------------
Renato Almeida de Brito
------------------------------

OK, I think I understand where the misunderstanding is. Normally, importing with CSNBKIM will take the CV into account.

It's not KYT where the problem crops up. When you used KIM, you ended up with a different key because the control vector was non-zero. You genuinely ended up with three different clear key materials inside each of the tokens you created.

I'm assuming you are encrypting the key material directly with raw KEK key material outside of CCA (and ICSF).

There is a way to do what you are asking about but it's not generally recommended for security reasons (using the same key material for multiple uses violates many separation-of-duty rules. If you use a NOCV IMPORTER, it will treat the input as if it was not encrypted with a control vector-modified KEK.

Note 1: You MUST be running in supervisor state to use NOCV KEK tokens. You must use a label if you need to run in problem state.
Note 2: You cannot use rule "TOKEN" with a NOCV IMPORTER. You have to specify the key type.
Note 3: It is possible for the access control points on the crypto card to disallow usage of a NOCV KEK.

------------------------------
Eric Rossman
------------------------------

Original Message:
Sent: Wed September 01, 2021 06:20 PM
From: Renato Almeida de Brito
Subject: Different KCV values for the same clear key value.



Eric, thanks for your reply. The point is that the key I'm importing is encrypted by a KEK, so I'm using CSNBKIM. Can I use CSNBSKM to import a key encrypted by a KEK? The problem is that the type of this encrypted key is MAC and the KCV I'm getting from our partner only hits when I import the key as DATA. I would like to know if there is a way to not consider the Control Vector in CSNBKYT so that I don't need to "import" the key twice just to confirm the KCV value.

------------------------------
Renato Almeida de Brito

Original Message:
Sent: Wed September 01, 2021 05:29 PM
From: Eric Rossman
Subject: Different KCV values for the same clear key value.

As written above, you are not importing clear key material. When you call KIM with a NULL token containing key material, that tells ICSF to treat the key material as already encrypted.

From Appendix B. Key token formats:

Null key tokens

With some callable services, a null key token can be used instead of an internal or an external key token.
A service generally accepts a null key token as a signal to use a key token with default values. A null key
token always has a value of X'00' as its first byte.

Null AES fixed-length key token
       A null AES key-token consisting of 64 bytes of X'00'.

Null DES fixed-length key token
       A null DES key-token consisting of 64 bytes of X'00'.

       The CSNBKIM callable service accepts input with offset zero valued to X'00'. In this special case, the
       service treats information that starts at offset 16 as an enciphered, single-length or double-length
       key.

What happens is that CSNBKIM will treat the single or double-length key material as it was already encrypted by the importer_key_identifier. Since all three key types have different control vectors, the actual key material that will be used will not be the same after import.

I think you want the CSNBSKM callable service for this.

------------------------------
Eric Rossman

Original Message:
Sent: Wed September 01, 2021 04:54 PM
From: Renato Almeida de Brito
Subject: Different KCV values for the same clear key value.

I'm using CSNBKIM to import a DES key (double length) and when I run CSNBKYT (ENC-ZERO) the result changes as I change the key type even though the clear key value is the same. Can anyone explain the reason and if there is how I can generate the KCV without taking into account the type of key?



* KIM_KEY_TYPE..: MAC
* KIM_SOURCE_KEY: 00000000000000000000000000000000F87AFBF7A839878589E91D31B580E92D
* KIM_TARGET_KEY: 010000000000C000A6A478E2E97CE31A95DC4536FD3F90A6000000000000000000054D0003000000000000000000000000000000000000000000000027433ED8
* KYT_KCV.......: E954C35D00000000
-------------------------------------------------------------------------------

* KIM_KEY_TYPE..: DATA
* KIM_SOURCE_KEY: 00000000000000000000000000000000F87AFBF7A839878589E91D31B580E92D
* KIM_TARGET_KEY: 010000000100C000A6A478E2E97CE31AD0F6D06C711173ADF5BC2A2AFAD0CDA500000000000000000000000000000000000000000000000000000010C4B757F4
* KYT_KCV.......: 80F1F0E800000000
-------------------------------------------------------------------------------

* KIM_KEY_TYPE..: IPINENC
* KIM_SOURCE_KEY: 00000000000000000000000000000000F87AFBF7A839878589E91D31B580E92D
* KIM_TARGET_KEY: 010000000000C000A6A478E2E97CE31A70D41BBFFF8E26DD2E0996EF73248ABE00215F000341000000215F0003210000000000000000000000000000A9573E45
* KYT_KCV.......: FE456CCC00000000
-------------------------------------------------------------------------------


Renato Brito.

------------------------------
Renato Almeida de Brito
------------------------------

Eric, using NOCV-KEK with label, it's OK.
I had tried NOCV-KEK, but as I was using TOKEN and had problems with the supervisor state, I didn't know it was possible to get around this restriction by using a label.
Thanks a lot for the help.

------------------------------
Renato Almeida de Brito
------------------------------

Original Message:
Sent: Wed September 01, 2021 06:51 PM
From: Eric Rossman
Subject: Different KCV values for the same clear key value.

OK, I think I understand where the misunderstanding is. Normally, importing with CSNBKIM will take the CV into account.

It's not KYT where the problem crops up. When you used KIM, you ended up with a different key because the control vector was non-zero. You genuinely ended up with three different clear key materials inside each of the tokens you created.

I'm assuming you are encrypting the key material directly with raw KEK key material outside of CCA (and ICSF).

There is a way to do what you are asking about but it's not generally recommended for security reasons (using the same key material for multiple uses violates many separation-of-duty rules. If you use a NOCV IMPORTER, it will treat the input as if it was not encrypted with a control vector-modified KEK.

Note 1: You MUST be running in supervisor state to use NOCV KEK tokens. You must use a label if you need to run in problem state.
Note 2: You cannot use rule "TOKEN" with a NOCV IMPORTER. You have to specify the key type.
Note 3: It is possible for the access control points on the crypto card to disallow usage of a NOCV KEK.

------------------------------
Eric Rossman

Original Message:
Sent: Wed September 01, 2021 06:20 PM
From: Renato Almeida de Brito
Subject: Different KCV values for the same clear key value.



Eric, thanks for your reply. The point is that the key I'm importing is encrypted by a KEK, so I'm using CSNBKIM. Can I use CSNBSKM to import a key encrypted by a KEK? The problem is that the type of this encrypted key is MAC and the KCV I'm getting from our partner only hits when I import the key as DATA. I would like to know if there is a way to not consider the Control Vector in CSNBKYT so that I don't need to "import" the key twice just to confirm the KCV value.

------------------------------
Renato Almeida de Brito

Original Message:
Sent: Wed September 01, 2021 05:29 PM
From: Eric Rossman
Subject: Different KCV values for the same clear key value.

As written above, you are not importing clear key material. When you call KIM with a NULL token containing key material, that tells ICSF to treat the key material as already encrypted.

From Appendix B. Key token formats:

Null key tokens

With some callable services, a null key token can be used instead of an internal or an external key token.
A service generally accepts a null key token as a signal to use a key token with default values. A null key
token always has a value of X'00' as its first byte.

Null AES fixed-length key token
       A null AES key-token consisting of 64 bytes of X'00'.

Null DES fixed-length key token
       A null DES key-token consisting of 64 bytes of X'00'.

       The CSNBKIM callable service accepts input with offset zero valued to X'00'. In this special case, the
       service treats information that starts at offset 16 as an enciphered, single-length or double-length
       key.

What happens is that CSNBKIM will treat the single or double-length key material as it was already encrypted by the importer_key_identifier. Since all three key types have different control vectors, the actual key material that will be used will not be the same after import.

I think you want the CSNBSKM callable service for this.

------------------------------
Eric Rossman

Original Message:
Sent: Wed September 01, 2021 04:54 PM
From: Renato Almeida de Brito
Subject: Different KCV values for the same clear key value.

I'm using CSNBKIM to import a DES key (double length) and when I run CSNBKYT (ENC-ZERO) the result changes as I change the key type even though the clear key value is the same. Can anyone explain the reason and if there is how I can generate the KCV without taking into account the type of key?



* KIM_KEY_TYPE..: MAC
* KIM_SOURCE_KEY: 00000000000000000000000000000000F87AFBF7A839878589E91D31B580E92D
* KIM_TARGET_KEY: 010000000000C000A6A478E2E97CE31A95DC4536FD3F90A6000000000000000000054D0003000000000000000000000000000000000000000000000027433ED8
* KYT_KCV.......: E954C35D00000000
-------------------------------------------------------------------------------

* KIM_KEY_TYPE..: DATA
* KIM_SOURCE_KEY: 00000000000000000000000000000000F87AFBF7A839878589E91D31B580E92D
* KIM_TARGET_KEY: 010000000100C000A6A478E2E97CE31AD0F6D06C711173ADF5BC2A2AFAD0CDA500000000000000000000000000000000000000000000000000000010C4B757F4
* KYT_KCV.......: 80F1F0E800000000
-------------------------------------------------------------------------------

* KIM_KEY_TYPE..: IPINENC
* KIM_SOURCE_KEY: 00000000000000000000000000000000F87AFBF7A839878589E91D31B580E92D
* KIM_TARGET_KEY: 010000000000C000A6A478E2E97CE31A70D41BBFFF8E26DD2E0996EF73248ABE00215F000341000000215F0003210000000000000000000000000000A9573E45
* KYT_KCV.......: FE456CCC00000000
-------------------------------------------------------------------------------


Renato Brito.

------------------------------
Renato Almeida de Brito
------------------------------

So glad to hear you got it all working!

------------------------------
Eric Rossman
------------------------------

Original Message:
Sent: Wed September 01, 2021 08:25 PM
From: Renato Almeida de Brito
Subject: Different KCV values for the same clear key value.

Eric, using NOCV-KEK with label, it's OK.
I had tried NOCV-KEK, but as I was using TOKEN and had problems with the supervisor state, I didn't know it was possible to get around this restriction by using a label.
Thanks a lot for the help.

------------------------------
Renato Almeida de Brito

Original Message:
Sent: Wed September 01, 2021 06:51 PM
From: Eric Rossman
Subject: Different KCV values for the same clear key value.

OK, I think I understand where the misunderstanding is. Normally, importing with CSNBKIM will take the CV into account.

It's not KYT where the problem crops up. When you used KIM, you ended up with a different key because the control vector was non-zero. You genuinely ended up with three different clear key materials inside each of the tokens you created.

I'm assuming you are encrypting the key material directly with raw KEK key material outside of CCA (and ICSF).

There is a way to do what you are asking about but it's not generally recommended for security reasons (using the same key material for multiple uses violates many separation-of-duty rules. If you use a NOCV IMPORTER, it will treat the input as if it was not encrypted with a control vector-modified KEK.

Note 1: You MUST be running in supervisor state to use NOCV KEK tokens. You must use a label if you need to run in problem state.
Note 2: You cannot use rule "TOKEN" with a NOCV IMPORTER. You have to specify the key type.
Note 3: It is possible for the access control points on the crypto card to disallow usage of a NOCV KEK.

------------------------------
Eric Rossman

Original Message:
Sent: Wed September 01, 2021 06:20 PM
From: Renato Almeida de Brito
Subject: Different KCV values for the same clear key value.



Eric, thanks for your reply. The point is that the key I'm importing is encrypted by a KEK, so I'm using CSNBKIM. Can I use CSNBSKM to import a key encrypted by a KEK? The problem is that the type of this encrypted key is MAC and the KCV I'm getting from our partner only hits when I import the key as DATA. I would like to know if there is a way to not consider the Control Vector in CSNBKYT so that I don't need to "import" the key twice just to confirm the KCV value.

------------------------------
Renato Almeida de Brito

Original Message:
Sent: Wed September 01, 2021 05:29 PM
From: Eric Rossman
Subject: Different KCV values for the same clear key value.

As written above, you are not importing clear key material. When you call KIM with a NULL token containing key material, that tells ICSF to treat the key material as already encrypted.

From Appendix B. Key token formats:

Null key tokens

With some callable services, a null key token can be used instead of an internal or an external key token.
A service generally accepts a null key token as a signal to use a key token with default values. A null key
token always has a value of X'00' as its first byte.

Null AES fixed-length key token
       A null AES key-token consisting of 64 bytes of X'00'.

Null DES fixed-length key token
       A null DES key-token consisting of 64 bytes of X'00'.

       The CSNBKIM callable service accepts input with offset zero valued to X'00'. In this special case, the
       service treats information that starts at offset 16 as an enciphered, single-length or double-length
       key.

What happens is that CSNBKIM will treat the single or double-length key material as it was already encrypted by the importer_key_identifier. Since all three key types have different control vectors, the actual key material that will be used will not be the same after import.

I think you want the CSNBSKM callable service for this.

------------------------------
Eric Rossman

Original Message:
Sent: Wed September 01, 2021 04:54 PM
From: Renato Almeida de Brito
Subject: Different KCV values for the same clear key value.

I'm using CSNBKIM to import a DES key (double length) and when I run CSNBKYT (ENC-ZERO) the result changes as I change the key type even though the clear key value is the same. Can anyone explain the reason and if there is how I can generate the KCV without taking into account the type of key?



* KIM_KEY_TYPE..: MAC
* KIM_SOURCE_KEY: 00000000000000000000000000000000F87AFBF7A839878589E91D31B580E92D
* KIM_TARGET_KEY: 010000000000C000A6A478E2E97CE31A95DC4536FD3F90A6000000000000000000054D0003000000000000000000000000000000000000000000000027433ED8
* KYT_KCV.......: E954C35D00000000
-------------------------------------------------------------------------------

* KIM_KEY_TYPE..: DATA
* KIM_SOURCE_KEY: 00000000000000000000000000000000F87AFBF7A839878589E91D31B580E92D
* KIM_TARGET_KEY: 010000000100C000A6A478E2E97CE31AD0F6D06C711173ADF5BC2A2AFAD0CDA500000000000000000000000000000000000000000000000000000010C4B757F4
* KYT_KCV.......: 80F1F0E800000000
-------------------------------------------------------------------------------

* KIM_KEY_TYPE..: IPINENC
* KIM_SOURCE_KEY: 00000000000000000000000000000000F87AFBF7A839878589E91D31B580E92D
* KIM_TARGET_KEY: 010000000000C000A6A478E2E97CE31A70D41BBFFF8E26DD2E0996EF73248ABE00215F000341000000215F0003210000000000000000000000000000A9573E45
* KYT_KCV.......: FE456CCC00000000
-------------------------------------------------------------------------------


Renato Brito.

------------------------------
Renato Almeida de Brito
------------------------------