Hello community, here is the log from the commit of package openCryptoki for openSUSE:Factory checked in at 2014-09-06 12:18:59 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Comparing /work/SRC/openSUSE:Factory/openCryptoki (Old) and /work/SRC/openSUSE:Factory/.openCryptoki.new (New) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "openCryptoki" Changes: -------- --- /work/SRC/openSUSE:Factory/openCryptoki/openCryptoki.changes 2014-09-03 20:28:23.000000000 +0200 +++ /work/SRC/openSUSE:Factory/.openCryptoki.new/openCryptoki.changes 2014-09-06 16:59:57.000000000 +0200 @@ -1,0 +2,33 @@ +Fri Sep 5 15:30:59 UTC 2014 - jjo...@suse.com + +- Fixed ica token's SHA update function when passing zero message + size (bnc#892644) +- Added patch ocki-3.1_10_0001-ica-sha-update-empty-msg.patch + +------------------------------------------------------------------- +Fri Sep 5 04:05:02 UTC 2014 - jjo...@suse.com + +- Fixed README.ep11_stdll to have Unix-style EOL characters. +- Added patch ocki-3.1_09_0001-Fix-EOL-encoding-in-README.patch + +------------------------------------------------------------------- +Thu Sep 4 21:51:32 UTC 2014 - jjo...@suse.com + +- Added all files from %src/doc as rpm %doc (bnc#894780) + +------------------------------------------------------------------- +Thu Sep 4 21:17:04 UTC 2014 - jjo...@suse.com + +- Added pkcscca utility and documentation to convert private + token objects from v2 to v3. (bnc#893757) +- Added patches: + - ocki-3.1_08_0001-Add-a-pkcscca-tool-to-help-migrate-cca-private-token.patch + - ocki-3.1_08_0002-Add-documentation-pkcscca-manpage-and-README.cca_std.patch + +------------------------------------------------------------------- +Thu Sep 4 20:35:01 UTC 2014 - jjo...@suse.com + +- Fixed pkcsslotd and opencryptoki.conf man pages (bnc#889183) +- Added patch ocki-3.1_07_0001-Man-page-corrections.patch + +------------------------------------------------------------------- New: ---- ocki-3.1_07_0001-Man-page-corrections.patch ocki-3.1_08_0001-Add-a-pkcscca-tool-to-help-migrate-cca-private-token.patch ocki-3.1_08_0002-Add-documentation-pkcscca-manpage-and-README.cca_std.patch ocki-3.1_09_0001-Fix-EOL-encoding-in-README.patch ocki-3.1_10_0001-ica-sha-update-empty-msg.patch ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Other differences: ------------------ ++++++ openCryptoki.spec ++++++ --- /var/tmp/diff_new_pack.Hfuy2R/_old 2014-09-06 16:59:58.000000000 +0200 +++ /var/tmp/diff_new_pack.Hfuy2R/_new 2014-09-06 16:59:58.000000000 +0200 @@ -74,6 +74,11 @@ Patch14: ocki-3.1_06_0005-Small-reworks.patch Patch15: ocki-3.1_06_0006-The-31-bit-build-on-s390-showed-an-build-error-at-in.patch Patch16: ocki-3.1_06_0007-ep11-is-not-building-because-not-setting-with_zcrypt.patch +Patch17: ocki-3.1_07_0001-Man-page-corrections.patch +Patch18: ocki-3.1_08_0001-Add-a-pkcscca-tool-to-help-migrate-cca-private-token.patch +Patch19: ocki-3.1_08_0002-Add-documentation-pkcscca-manpage-and-README.cca_std.patch +Patch20: ocki-3.1_09_0001-Fix-EOL-encoding-in-README.patch +Patch21: ocki-3.1_10_0001-ica-sha-update-empty-msg.patch Url: http://oss.software.ibm.com/developerworks/opensource/opencryptoki BuildRoot: %{_tmppath}/%{name}-%{version}-build PreReq: /usr/sbin/groupadd /usr/bin/id /usr/sbin/usermod /bin/sed %insserv_prereq @@ -167,6 +172,11 @@ %patch14 -p1 %patch15 -p1 %patch16 -p1 +%patch17 -p1 +%patch18 -p1 +%patch19 -p1 +%patch20 -p1 +%patch21 -p1 cp %{SOURCE2} . %build @@ -285,6 +295,7 @@ %files %defattr(-,root,root) %doc openCryptoki-TFAQ.html +%doc doc/* # configuration directory %dir %{_sysconfdir}/opencryptoki %config %{_sysconfdir}/opencryptoki/opencryptoki.conf @@ -307,6 +318,7 @@ %{_sbindir}/pkcsslotd %{_sbindir}/pkcsconf %{_sbindir}/pkcsicsf +%{_sbindir}/pkcscca %dir %{_libdir}/opencryptoki %dir %{_libdir}/opencryptoki/stdll # State and lock directories ++++++ ocki-3.1-fix-implicit-decl.patch ++++++ --- /var/tmp/diff_new_pack.Hfuy2R/_old 2014-09-06 16:59:58.000000000 +0200 +++ /var/tmp/diff_new_pack.Hfuy2R/_new 2014-09-06 16:59:58.000000000 +0200 @@ -1,5 +1,5 @@ ---- opencryptoki.orig/usr/lib/pkcs11/common/loadsave.c 2014-01-27 15:01:58.000000000 -0700 -+++ opencryptoki/usr/lib/pkcs11/common/loadsave.c 2014-01-31 10:56:26.377812000 -0700 +--- opencryptoki/usr/lib/pkcs11/common/loadsave.c ++++ opencryptoki/usr/lib/pkcs11/common/loadsave.c @@ -287,6 +287,9 @@ // // @@ -10,8 +10,8 @@ #include <pthread.h> #include <stdio.h> #include <stdlib.h> ---- opencryptoki.orig/usr/lib/pkcs11/common/mech_rng.c 2014-01-27 15:01:58.000000000 -0700 -+++ opencryptoki/usr/lib/pkcs11/common/mech_rng.c 2014-01-31 11:00:30.004283000 -0700 +--- opencryptoki/usr/lib/pkcs11/common/mech_rng.c ++++ opencryptoki/usr/lib/pkcs11/common/mech_rng.c @@ -301,6 +301,7 @@ #include <sys/types.h> #include <sys/stat.h> @@ -20,8 +20,20 @@ #include "pkcs11types.h" ---- opencryptoki.orig/usr/sbin/pkcsslotd/garbage_linux.c 2014-01-27 15:01:58.000000000 -0700 -+++ opencryptoki/usr/sbin/pkcsslotd/garbage_linux.c 2014-01-31 11:03:14.422314000 -0700 +--- opencryptoki/usr/lib/pkcs11/tpm_stdll/tpm_specific.c ++++ opencryptoki/usr/lib/pkcs11/tpm_stdll/tpm_specific.c +@@ -31,6 +31,9 @@ + * + */ + ++#define _GNU_SOURCE ++#include <stdio.h> ++ + #include <pthread.h> + #include <string.h> + #include <stdlib.h> +--- opencryptoki/usr/sbin/pkcsslotd/garbage_linux.c ++++ opencryptoki/usr/sbin/pkcsslotd/garbage_linux.c @@ -294,6 +294,7 @@ #include <string.h> #include <sys/types.h> @@ -30,8 +42,8 @@ #include "log.h" #include "slotmgr.h" ---- opencryptoki.orig/usr/sbin/pkcsslotd/mutex.c 2014-01-31 11:08:15.000000000 -0700 -+++ opencryptoki/usr/sbin/pkcsslotd/mutex.c 2014-01-31 11:08:25.929081000 -0700 +--- opencryptoki/usr/sbin/pkcsslotd/mutex.c ++++ opencryptoki/usr/sbin/pkcsslotd/mutex.c @@ -293,6 +293,9 @@ #include <sys/types.h> #include <sys/file.h> @@ -42,8 +54,8 @@ #include "log.h" #include "slotmgr.h" ---- opencryptoki.orig/usr/sbin/pkcsslotd/slotmgr.c 2014-01-27 15:01:58.000000000 -0700 -+++ opencryptoki/usr/sbin/pkcsslotd/slotmgr.c 2014-01-31 11:12:08.708122000 -0700 +--- opencryptoki/usr/sbin/pkcsslotd/slotmgr.c ++++ opencryptoki/usr/sbin/pkcsslotd/slotmgr.c @@ -292,6 +292,7 @@ #include <stdio.h> #include <stdlib.h> @@ -52,15 +64,3 @@ #include "log.h" #include "slotmgr.h" ---- opencryptoki.orig/usr/lib/pkcs11/tpm_stdll/tpm_specific.c 2014-01-27 15:01:58.000000000 -0700 -+++ opencryptoki/usr/lib/pkcs11/tpm_stdll/tpm_specific.c 2014-01-31 11:16:45.158228000 -0700 -@@ -31,6 +31,9 @@ - * - */ - -+#define _GNU_SOURCE -+#include <stdio.h> -+ - #include <pthread.h> - #include <string.h> - #include <stdlib.h> ++++++ ocki-3.1-remove-make-install-chgrp-chmod.patch ++++++ --- /var/tmp/diff_new_pack.Hfuy2R/_old 2014-09-06 16:59:58.000000000 +0200 +++ /var/tmp/diff_new_pack.Hfuy2R/_new 2014-09-06 16:59:58.000000000 +0200 @@ -84,9 +84,9 @@ uninstall-hook: if test -d $(DESTDIR)$(libdir)/opencryptoki/stdll; then \ ---- opencryptoki.orig/usr/lib/pkcs11/tpm_stdll/Makefile.am 2014-01-27 15:01:58.000000000 -0700 -+++ opencryptoki/usr/lib/pkcs11/tpm_stdll/Makefile.am 2014-01-31 08:20:37.999866000 -0700 -@@ -69,11 +69,7 @@ install-data-hook: +--- opencryptoki/usr/lib/pkcs11/tpm_stdll/Makefile.am ++++ opencryptoki/usr/lib/pkcs11/tpm_stdll/Makefile.am +@@ -69,11 +69,7 @@ cd $(DESTDIR)$(libdir)/opencryptoki/stdll && \ ln -sf libpkcs11_tpm.so PKCS11_TPM.so $(MKDIR_P) $(DESTDIR)$(localstatedir)/lib/opencryptoki/tpm ++++++ ocki-3.1_07_0001-Man-page-corrections.patch ++++++ >From 417e55a76a3a52dfb22f0055230c74b083d9e3a7 Mon Sep 17 00:00:00 2001 From: Joy Latten <jmlat...@linux.vnet.ibm.com> Date: Fri, 29 Aug 2014 12:40:35 -0500 Subject: [PATCH] Man page corrections. Remove references to obsoleted pk_config_data and pkcs11_startup in the pkcsslotd man page. Other changes made as necessary. Signed-off-by: Joy Latten <jmlat...@linux.vnet.ibm.com> --- man/man5/opencryptoki.conf.5.in | 12 +++++++++++- man/man8/pkcsslotd.8.in | 6 ++---- 2 files changed, 13 insertions(+), 5 deletions(-) diff --git a/man/man5/opencryptoki.conf.5.in b/man/man5/opencryptoki.conf.5.in index e13c110..f3aabd1 100644 --- a/man/man5/opencryptoki.conf.5.in +++ b/man/man5/opencryptoki.conf.5.in @@ -3,7 +3,7 @@ opencryptoki.conf \- Configuration file for pkcsslotd. .SH DESCRIPTION -pkcsslotd uses a configuration file at "@sysconfdir@"/opencryptoki.conf +pkcsslotd uses a configuration file at @sysconfdir@/opencryptoki/opencryptoki.conf This is a text file that contains information used to configure pkcs#11 slots. At startup, the pkcsslotd daemon parses this file to @@ -51,6 +51,16 @@ Version number of the slot's firmware, if any. The version number is composed of a major version number (the integer portion of the version) and a minor version number (the hundredths portion of the version). .TP +.BR confname +If the slot is associated with a token that has its own configuration file, +this option identifies the name of that configuration file. +For example, confname=ep11tok.conf + +.SH Notes +The pound sign ('#') is used to indicate a comment. +Both the comment character and any text after it, up to the end of the line, +are ignored. The comment character cannot be used inside the brackets of +slot descriptions, as this will cause a syntax error. .SH "SEE ALSO" .PD 0 diff --git a/man/man8/pkcsslotd.8.in b/man/man8/pkcsslotd.8.in index c5d7280..db113e9 100644 --- a/man/man8/pkcsslotd.8.in +++ b/man/man8/pkcsslotd.8.in @@ -29,9 +29,7 @@ manual page for details. .TP \fBopencryptoki\fP(7), .TP -\fBpkcsconf\fP(1), -.TP -\fBpk_config_data\fP(5), +\fBopencryptoki.conf\fP(5), .TP -\fBpkcs11_startup\fP(1). +\fBpkcsconf\fP(1), .PD -- 1.8.1.4 ++++++ ocki-3.1_08_0001-Add-a-pkcscca-tool-to-help-migrate-cca-private-token.patch ++++++ ++++ 783 lines (skipped) ++++++ ocki-3.1_08_0002-Add-documentation-pkcscca-manpage-and-README.cca_std.patch ++++++ >From 13eda6d102b8c44f85cf4eac094ff8a964c630f4 Mon Sep 17 00:00:00 2001 From: Joy Latten <jmlat...@linux.vnet.ibm.com> Date: Mon, 1 Sep 2014 22:46:37 -0500 Subject: [PATCH 2/2] Add documentation (pkcscca manpage and README.cca_stdll) to assist in migrating cca private token objects from v2 to v3. Signed-off-by: Joy Latten <jmlat...@linux.vnet.ibm.com> --- configure.in | 1 + doc/README.cca_stdll | 175 ++++++++++++++++++++++++++++++++++++++++++++++---- man/man1/Makefile.am | 2 +- man/man1/pkcscca.1.in | 45 +++++++++++++ 4 files changed, 209 insertions(+), 14 deletions(-) create mode 100644 man/man1/pkcscca.1.in diff --git a/configure.in b/configure.in index f3fbe70..3e7e5e8 100644 --- a/configure.in +++ b/configure.in @@ -843,6 +843,7 @@ AC_CONFIG_FILES([Makefile usr/Makefile \ man/man1/Makefile \ man/man1/pkcsconf.1 \ man/man1/pkcsicsf.1 \ + man/man1/pkcscca.1 \ man/man1/pkcsep11_migrate.1 \ man/man5/Makefile \ man/man5/opencryptoki.conf.5 \ diff --git a/doc/README.cca_stdll b/doc/README.cca_stdll index f535dfa..a0d13f1 100644 --- a/doc/README.cca_stdll +++ b/doc/README.cca_stdll @@ -1,24 +1,173 @@ +CCA TOKEN -README for the CCA secure-key token +OverView +-------- +The CCA token is a secure key token. +A Secure key - key value does not exist in the clear outside of the HSM +(secure, tamper-resistent boundary of the card). It is a clear key wrapped +with the appropriate MasterKey that has been installed into the secure hardware. +A clear key is generated in the hardware, wrapped with the appropriate +master key that has been installed into the hardware. The wrapped key is then +passed back to the invoker. Upon an encryption and/or decryption request, +the wrapped key and the data to be encrypted are passed into the hardware. +The wrapped key is verified, and the clear key is used to encrypt and/or +decrypt the data. All this is done in the CCA hardware. -Kent Yoder <yod...@us.ibm.com> +Within opencryptoki, this wrapped key value is stored in the CKA_IBM_OPAQUE +attribute rather than the CKA_VALUE attribute. - The key used to encrypt private objects on disk is a secure key. +Pre-requisites: +The CCA token requires cca library, libcsulcca.so, which is part of the +csulcca rpm. +It also requires proper configuration and installation of the MK keys into +the hardware which is outside the scope of this document. - The key used to encrypt that secure key is based on the hash of the -USER and SO pins. Therefore it is a clear key and software is used to -do the encryption/decryption of the secure key. +Configuration +------------- -MK_USER: The secure key used for internal on-disk encryption, encrypted +To use the CCA token a slot entry must be defined in the +opencryptoki.conf configuration file that sets the stdll attribute to +libcsulcca.so. + +The CCA token also requires that the appropriate master keys have +been installed into the hardware. The corresponding driver must also be +loaded, i.e. modprobe z90crypt. + +CCA Token Objects +------------------------- + +Opencryptoki stores token objects on disk. Public token objects are not +encrypted. Private token objects are encrypted. +Versions of opencryptoki prior to version 3, used a CCA generated secure key +(des3 key) and the crypto adapter to encrypt the private token object's data. +In version 3, a clear key (des3 key) and software crypto (openssl) are used +to encrypt this data. + +Migration Information +--------------------- + +Migrating version 2 private token objects to version 3 is ONLY required if +the system will run opencryptoki version 3 and will use private token +objects saved or preserved from version 2. +Note, public token objects do not need to be migrated. +If there are no private token objects from version 2, then the version 3 +does not require any migrating. + +In version 2 private token objects are encrypted and decrypted with a secure +key in the crypto adapter. In version 3, this encryption and decryption is +done with a clear key using software crypto. Therefore, opencryptoki +version 3, will not succesfully decrypt a version 2 private token object. + +Version 2 private token objects must be "migrated" to version 3 so that +opencryptoki version 3 can access these objects. This migration will +decrypt the objects using the CCA call, CSNBDEC and the current +opencryptoki key stored in MK_USER. The objects will then be re-encrypted +using software crypto. The key bits that are stored in MK_USER will then be +used as a clear key. + +Once the migration has completed, these private token objects should then be +accessable to version 3. + +Migration Steps +--------------- + +1. Either update or install version 3. +a. Update to opencryptoki version 3. In most linux distributions, an update +from version 2 to version 3 will preserve the contents of the CCA data-store. + +b. Install opencryptoki version 3. In most distributions, an install will +remove the contents of the CCA data-store. You will essentially be starting +from the beginning and have to initialize the CCA token. + +In this scenario, if a prior version of opencryptoki had been running on the +system, and you wanted to preserve your token objects, you will have saved +or backed them up somewhere. + +2. Backup the CCA data-store before migrating. It is always a good idea to +back up the data in case the migration is unsuccessful or data is corrupted. +The data-store is the directory in which the CCA token information is stored +on disk. In most distributions it can be found in /var/lib/opencryptoki/ccatok. +Within this directory there is, + +MK_USER: The des3 key used for internal on-disk encryption, encrypted under the USER's PIN by software routines -MK_SO: The secure key used for internal on-disk encryption, encrypted +MK_SO: The des3 key used for internal on-disk encryption, encrypted under the SO's PIN by software routines -So, MK_USER and MK_SO contain the same key, encrypted under different PINs +NKTOK.DAT: Token information. + +TOK_OBJ: The directory in which token objects are stored. + +TOK_OBJ/OBJ.IDX: A list of current token objects. + +**NOTE: MK_USER and MK_SO contain the same key, encrypted under +different PINs + +3. Ensure no opencryptoki processes are running. Stop the pkcsslotd daemon +if it is running. + +4. Run the pkcscca tool to perform the migration. +For example, + pkcscca -m v2objectsv3 -v + +Note that the "-v" option will allow you to see which objects did and did not +get migrated. Specify the "-d" flag if you wish to migrate CCA token objects +stored in a data-store different from the default, /var/lib/opencryptoki/ccatok. + +5. (Optional) Removing shared memory may be required to pick up +the newly migrated objects. + +CCA token's shared memory segment tracks its token objects. +Token objects stored on disk are only loaded into shared memory +when the shared memory is created. The shared memory is usually +created after a reboot, an install, or an update of the opencryptoki package. + +If another opencryptoki process accessed the CCA token after install +or update, then opencryptoki will have loaded all the token objects into +shared memory, except for the private token objects requiring migration, +since they will have failed decryption. Subsequent calls to the +opencryptoki api will not find these objects since they have not +been loaded into shared memory. Opencryptoki won't read the +objects from disk and load into shared memory again until the next time +shared memory is created. + +So, in this case, shared memory must be removed and created again so +that opencryptoki can successfuly load all the token objects including the +newly migrated private token objects into CCA token's shared memory segment. + +Remove shared memory if, + - after updating or installing, any opencryptoki processes or tools tried + to access the CCA token before migrating CCA token's private token + objects. For example, the pkcsconf command was run. + + The pre-migrated objects will have failed decryption and not + been loaded into shared memory. A reboot or removing shared memory + will cause the token to create shared memory again and load the newly + migrated private token objects into it. + +CCA's shared memory can be removed two ways. + 1. a reboot + + 2. remove the shared memory file, + i.e. "rm /dev/shm/var.lib.opencryptoki.ccatok" + + Notes: (1). Ensure that no opencryptoki processes are running + before removing the shared memory. Otherwise, you risk corrupting + any running opencryptoki processes. + (2). If you have installed opencryptoki manually (not via a distro + rpm) the CCA token shared memory segment may be named + usr.local.var.lib.opencryptoki.ccatok. + +The next opencryptoki process to run will cause opencryptoki to create +a shared memory segment for the token and load the newly migrated objects +as well as any other token objects for the token. -PKCS#11 Notes: +6. After a successful migration, the CCA private token objects should be +encrypted and ready to be accessed by opencryptoki version 3. -DES/3DES PKCS#11 key objects have the CCA key identifier stored in the CKA_VALUE -attribute. Usually the CKA_VALUE attribute would hold a plaintext key, however -in this case, the id used to reference the secure key is stored here. +TroubleShooting: +1. If version 3 cannot find the newly migrated CCA private token objects, +reboot or remove the shared memory file. This will cause token to create +shared memory again and load the newly migrated private token objects +into shared memory. diff --git a/man/man1/Makefile.am b/man/man1/Makefile.am index c4b4d95..f2274d7 100644 --- a/man/man1/Makefile.am +++ b/man/man1/Makefile.am @@ -1,3 +1,3 @@ -man1_MANS=pkcsconf.1 pkcsicsf.1 pkcsep11_migrate.1 +man1_MANS=pkcsconf.1 pkcsicsf.1 pkcsep11_migrate.1 pkcscca.1 EXTRA_DIST = $(man1_MANS) CLEANFILES = $(man1_MANS) diff --git a/man/man1/pkcscca.1.in b/man/man1/pkcscca.1.in new file mode 100644 index 0000000..c6e49d6 --- /dev/null +++ b/man/man1/pkcscca.1.in @@ -0,0 +1,45 @@ +.TH PKCSCCA 1 "September 2014" "@PACKAGE_VERSION@" "openCryptoki" +.SH NAME +pkcscca \- configuration utility for the CCA token + +.SH SYNOPSIS +\fBpkcscca\fP +[\fB-h\fP] +[\fB-m v2objectsv3\fP] +[\fIOPTIONS\fP] + +.SH DESCRIPTION +The \fBpkcscca\fP utility assists in administering the CCA token. Currently it +migrates opencryptoki version 2 private token objects to the encryption +method used in opencryptoki version 3. + +In verion 2 of opencryptoki, CCA private token objects were encrypted in CCA +hardware. In version 3 these objects are encrypted in software. The +\fBv2objectsv3\fP migration option migrates these version 2 objects by +decrypting them in CCA hardware using a secure key and then re-encrypting +them in software using a software key. Afterwards, v2 objects can be accessed +in version 3. + +.SH "FLAGS" +.IP "\fB-h\fP" 10 +show usage information +.IP "\fB-m\fP" 10 +perform a migration. \fBv2objectsv3\fP is currently the only type of migration +supported and must be specified along with this flag. + +.SH "MIGRATION OPTIONS" +.IP "\fB-d|--datastore\fP \fIdirectory\fp" 10 +the directory where the CCA token information is kept. This directory will be +used to locate the private token objects to be migrated. i.e. /var/lib/opencryptoki/ccatok +.IP "\fB-v|--verbose\fP" 10 +provide detailed output during migration + +.SH "FILES" +.IP "/var/lib/opencryptoki/ccatok/TOK_OBJ/OBJ.IDX" +contains current list of public and private token objects for the CCA token. + +.SH SEE ALSO +.PD 0 +.TP +\fBREADME.cca_stdll\fP (in system's doc directory) +.PD -- 1.8.1.4 ++++++ ocki-3.1_09_0001-Fix-EOL-encoding-in-README.patch ++++++ --- opencryptoki.orig/doc/README.ep11_stdll 2014-09-04 21:59:50.000000000 -0600 +++ opencryptoki/doc/README.ep11_stdll 2014-09-04 22:01:27.223654000 -0600 @@ -1,126 +1,126 @@ -EP11 Token -========== - -The EP11 token is a token that uses the IBM Crypto Express adapters -(starting with Crypto Express 4S adapters) configured with Enterprise -PKCS#11 (EP11) firmware. By convention, Crypto Express n adapters with that -firmware load are also called CEXnP adapters for n >= 4. - -The EP11 token is only supported on the System z architecture and requires a -Crypto Express adapter with EP11 firmware load, a zcrypt/ap device driver -loaded into the kernel and the availability of EP11 library libep11. - -The token directory of the EP11 token is opencryptoki/ep11tok typically -located in /var/lib. - -Configuration -------------- - -To use the EP11 token a slot entry must be defined in the general opencryptoki -configuration file that sets the stdll attribute to libpkcs11_ep11.so. - -A EP11 token specific configuration file must be set up to define the target -adapters and target adapter domains. The name of the configuration file must be -defined in the global openCryptoki configuration opencryptoki.conf file as part -of the token specification using the confname attribute. -E.g. the entry - -slot 4 -{ -stdll = libpkcs11_ep11.so -confname = ep11tok.conf -} - -defines the name of the configuration file of the EP11 token to be -ep11tok.conf. Per default this file is searched in the directory where -openCryptoki searches its global configuration file. This default path can -be overriden using the OCK_EP11_TOKEN_DIR environment variable. - -EP11 token configuration files defines a list of adapter/domain pairs to which -the EP11 token sends its cryptographic requests. This list can be specified as -a white list starting with a line containing the key word APQN_WHITELIST -followed by one or more lines containing each two integers (in the range -of 0 - 255) separated by a white space. The white list is ended with a line -containing the key word END. In each of lines of the white list the first -integer denotes the adapter number and the second integer denotes the domain -id. Alternatively the keyword APQN_ANY can be used to define that all -adapter/domain pairs with EP11 firmware load that are available to the system -shall be used as target adapters. An adapter number corresponds to the -numerical part xx of an adapter id of the form cardxx as displayed by the -lszcrypt tool or in the sys file system (e.g. in /sys/bus/ap/devices). -Currently Linux on z only supports a single domain. That domain number can be -displayed with lszcrypt -b (see the value of ap_domain) or alternatively as -contents of /sys/bus/ap/ap_domain. - -In addition to the target adapter a log level can be defined in the EP11 -configuration file using a line consisting of the key word LOGLEVEL followed -by an integer between 0 and 9. - -Logging -------- - -If a log level greater than 0 is defined in the environment variable -OCK_EP11_TOKEN_LOGLEVEL or using the LOGLEVEL entry in the EP11 configuration -file then log entries are written to a log file -/var/log/ock_ep11_token.<pid>.log where <pid> is the process id of the process -using the EP11 token. - -Note, that the handling of EP11 logs is subject to change in future releases -of opencryptoki. - -Crypto Express Adapter EP11 Master Key Management -------------------------------------------------- - -If master keys are changed on an EP11 adapter all key objects in the token -object repository (in the TOK_OBJ directory within the EP11 token directory) -become invalid. - -The key migration tool pkcsep11_migrate can be used to perform the migration -of the current EP11 master keys to new master keys. Therefore the following -steps must be performed: -1) On the Trusted Key Entry console (TKE): Submit and commit new master -keys on the EP11 adapter(s). -2) On Linux: Stop all processes using openCryptoki with the EP11 token. -3) On Linux: Back up the token object repository of the EP11 token. -4) On Linux: Migrate keys of object repository of EP11 token with -migration tool. If a failure occurs restore the backed up token repository -and retry step 4. -5) On the TKE: Activate new master keys on the EP11 adapter(s). -6) On Linux: Restart applications using openCryptoki with the EP11 token. - -Token specifics ---------------- - -The EP11 token only supports secure keys (i.e. key wrapped by a master key of -the Crypto Express adapter). Therefore all keys must have the attribute -CKA_SENISTIVE set to CK_TRUE. Since the PKCS#11 standard does not define a -(token specific) default for secure keys the attribute must be explicitly -provided whenever a secret key is generated, unwrapped or build with -C_CreateObject. In addition all keys used with the EP11 token are extractable. -i.e. they must have the attribute CKA_EXTRACTABLE set to CK_TRUE. - -When creating keys the default values of the attributes CKA_ENCRYPT, -CKA DECRYPT, CKA_VERYFY, CKA_SIGN, CKA_WRAP and CKA_UNWRAP are CK_TRUE. -Note, no EP11 mechanism supports the Sign/Recover or Verify/Recover functions. - -All RSA key must have a public exponent (CKA_PUBLIC_EXPONENT) greater than -or equal to 17. - -The CryptoExpress EP11 coprocessor restricts RSA keys (primes and moduli) -according to ANSI X9.31. Therefore in the EP11 token the lengths of the -RSA primes (p or q) must be a multiple of 128 bits and the length of the -modulus (CKA_MODULUS_BITS) must be a multiple of 256. - -The mechanisms CKM_DES3_CBC and CKM_AES_CBC can only wrap keys which have -a length that is a multiple of the block size of DES3 or AES respectively. - -See the mechanism list and mechanism info (pkcsconf -m) for supported -mechanisms together with supported functions and key sizes. Note the -supported mechanism list is currently fix and matches the most stringent -setting of the Crypto Express adapter. - -Note, the EP11 coprocessor adapter can be configured to restrict the -cryptographic capababilities in order for the adapter to comply with specific -security requirements and regulations. Such restrictions on the adapter impact -the capabilitiy of the EP11 token. - +EP11 Token +========== + +The EP11 token is a token that uses the IBM Crypto Express adapters +(starting with Crypto Express 4S adapters) configured with Enterprise +PKCS#11 (EP11) firmware. By convention, Crypto Express n adapters with that +firmware load are also called CEXnP adapters for n >= 4. + +The EP11 token is only supported on the System z architecture and requires a +Crypto Express adapter with EP11 firmware load, a zcrypt/ap device driver +loaded into the kernel and the availability of EP11 library libep11. + +The token directory of the EP11 token is opencryptoki/ep11tok typically +located in /var/lib. + +Configuration +------------- + +To use the EP11 token a slot entry must be defined in the general opencryptoki +configuration file that sets the stdll attribute to libpkcs11_ep11.so. + +A EP11 token specific configuration file must be set up to define the target +adapters and target adapter domains. The name of the configuration file must be +defined in the global openCryptoki configuration opencryptoki.conf file as part +of the token specification using the confname attribute. +E.g. the entry + +slot 4 +{ +stdll = libpkcs11_ep11.so +confname = ep11tok.conf +} + +defines the name of the configuration file of the EP11 token to be +ep11tok.conf. Per default this file is searched in the directory where +openCryptoki searches its global configuration file. This default path can +be overriden using the OCK_EP11_TOKEN_DIR environment variable. + +EP11 token configuration files defines a list of adapter/domain pairs to which +the EP11 token sends its cryptographic requests. This list can be specified as +a white list starting with a line containing the key word APQN_WHITELIST +followed by one or more lines containing each two integers (in the range +of 0 - 255) separated by a white space. The white list is ended with a line +containing the key word END. In each of lines of the white list the first +integer denotes the adapter number and the second integer denotes the domain +id. Alternatively the keyword APQN_ANY can be used to define that all +adapter/domain pairs with EP11 firmware load that are available to the system +shall be used as target adapters. An adapter number corresponds to the +numerical part xx of an adapter id of the form cardxx as displayed by the +lszcrypt tool or in the sys file system (e.g. in /sys/bus/ap/devices). +Currently Linux on z only supports a single domain. That domain number can be +displayed with lszcrypt -b (see the value of ap_domain) or alternatively as +contents of /sys/bus/ap/ap_domain. + +In addition to the target adapter a log level can be defined in the EP11 +configuration file using a line consisting of the key word LOGLEVEL followed +by an integer between 0 and 9. + +Logging +------- + +If a log level greater than 0 is defined in the environment variable +OCK_EP11_TOKEN_LOGLEVEL or using the LOGLEVEL entry in the EP11 configuration +file then log entries are written to a log file +/var/log/ock_ep11_token.<pid>.log where <pid> is the process id of the process +using the EP11 token. + +Note, that the handling of EP11 logs is subject to change in future releases +of opencryptoki. + +Crypto Express Adapter EP11 Master Key Management +------------------------------------------------- + +If master keys are changed on an EP11 adapter all key objects in the token +object repository (in the TOK_OBJ directory within the EP11 token directory) +become invalid. + +The key migration tool pkcsep11_migrate can be used to perform the migration +of the current EP11 master keys to new master keys. Therefore the following +steps must be performed: +1) On the Trusted Key Entry console (TKE): Submit and commit new master +keys on the EP11 adapter(s). +2) On Linux: Stop all processes using openCryptoki with the EP11 token. +3) On Linux: Back up the token object repository of the EP11 token. +4) On Linux: Migrate keys of object repository of EP11 token with +migration tool. If a failure occurs restore the backed up token repository +and retry step 4. +5) On the TKE: Activate new master keys on the EP11 adapter(s). +6) On Linux: Restart applications using openCryptoki with the EP11 token. + +Token specifics +--------------- + +The EP11 token only supports secure keys (i.e. key wrapped by a master key of +the Crypto Express adapter). Therefore all keys must have the attribute +CKA_SENISTIVE set to CK_TRUE. Since the PKCS#11 standard does not define a +(token specific) default for secure keys the attribute must be explicitly +provided whenever a secret key is generated, unwrapped or build with +C_CreateObject. In addition all keys used with the EP11 token are extractable. +i.e. they must have the attribute CKA_EXTRACTABLE set to CK_TRUE. + +When creating keys the default values of the attributes CKA_ENCRYPT, +CKA DECRYPT, CKA_VERYFY, CKA_SIGN, CKA_WRAP and CKA_UNWRAP are CK_TRUE. +Note, no EP11 mechanism supports the Sign/Recover or Verify/Recover functions. + +All RSA key must have a public exponent (CKA_PUBLIC_EXPONENT) greater than +or equal to 17. + +The CryptoExpress EP11 coprocessor restricts RSA keys (primes and moduli) +according to ANSI X9.31. Therefore in the EP11 token the lengths of the +RSA primes (p or q) must be a multiple of 128 bits and the length of the +modulus (CKA_MODULUS_BITS) must be a multiple of 256. + +The mechanisms CKM_DES3_CBC and CKM_AES_CBC can only wrap keys which have +a length that is a multiple of the block size of DES3 or AES respectively. + +See the mechanism list and mechanism info (pkcsconf -m) for supported +mechanisms together with supported functions and key sizes. Note the +supported mechanism list is currently fix and matches the most stringent +setting of the Crypto Express adapter. + +Note, the EP11 coprocessor adapter can be configured to restrict the +cryptographic capababilities in order for the adapter to comply with specific +security requirements and regulations. Such restrictions on the adapter impact +the capabilitiy of the EP11 token. + ++++++ ocki-3.1_10_0001-ica-sha-update-empty-msg.patch ++++++ commit 2094b476ab7c14caecc37add2da43bba11b71bf5 Author: Ingo Tuchscherer <ingo.tuchsche...@linux.vnet.ibm.com> Date: Fri Aug 15 12:48:46 2014 +0200 Fixed ica token's SHA update function when passing zero message size Signed-off-by: Ingo Tuchscherer <ingo.tuchsche...@linux.vnet.ibm.com> --- opencryptoki.orig/usr/lib/pkcs11/ica_s390_stdll/ica_specific.c 2014-01-27 15:01:58.000000000 -0700 +++ opencryptoki/usr/lib/pkcs11/ica_s390_stdll/ica_specific.c 2014-09-05 09:19:55.009080000 -0600 @@ -859,7 +859,7 @@ token_specific_sha_update( DIGEST_CONTEX * we're not stuck with 0 bytes when the MSG_PART_FINAL * comes in. - KEY */ - if (!(in_data_len % 64)) { + if (!(in_data_len % 64) && (in_data_len != 0)) { oc_sha_ctx->tail_len = 64; memcpy(oc_sha_ctx->tail, in_data + in_data_len - 64, 64); in_data_len -= 64; -- To unsubscribe, e-mail: opensuse-commit+unsubscr...@opensuse.org For additional commands, e-mail: opensuse-commit+h...@opensuse.org
