1 #
2 # CDDL HEADER START
3 #
4 # The contents of this file are subject to the terms of the
5 # Common Development and Distribution License (the "License").
6 # You may not use this file except in compliance with the License.
7 #
8 # You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
9 # or http://www.opensolaris.org/os/licensing.
10 # See the License for the specific language governing permissions
11 # and limitations under the License.
12 #
13 # When distributing Covered Code, include this CDDL HEADER in each
14 # file and include the License file at usr/src/OPENSOLARIS.LICENSE.
15 # If applicable, add the following below this CDDL HEADER, with the
16 # fields enclosed by brackets "[]" replaced with your own identifying
17 # information: Portions Copyright [yyyy] [name of copyright owner]
18 #
19 # CDDL HEADER END
20 #
21
22 #
23 # Copyright 2009 Sun Microsystems, Inc. All rights reserved.
24 # Use is subject to license terms.
25 #
26 # ident "@(#)README 1.10 09/09/03 SMI"
27 #
28
29 #
30 # README file for the KMF test suite.
31 #
32
33 1. INTRODUCTION
34 2. SYSTEM REQUIREMENTS
35 3. RUNNING TESTS
36 3.1 Installing Test Suite and Tools Packages
37 3.2 Configuring the Test System to Run the Test Suite
38 3.3 Executing Tests and Examining Results
39 3.4 Building Test Binaries from Source Code
40 4. TEST COVERAGE
41 5. NOTES
42 6. CONTACT US
43
44
45 1. INTRODUCTION
46
47 This test suite is a basic functionality test of the KMF (Key Management
48 Framework) library, and of the pktool(1) and kmfcfg(1) utilities.
49
50 This test suite uses STF, the second generation STC harness and operates
51 in the standard manner implemented by STF. Please see the "STF User's
52 Guide" for more information on STF.
53
54
55 2. SYSTEM REQUIREMENTS
56
57 This version of the test suite requires snv_123 or newer of Nevada.
58 This test suite can run on all architectures supported by Solaris.
59
60 STC_VERSION 1.8 and earlier of the KMF test suite require snv_73
61 or earlier. Versions 1.8 through 2.10 require snv_74 or later,
62 but not newer than snv_103.
63
64 Special requirements for running this test suite on systems with a TPM device,
65 e.g. Ultra 40 M2, T5120/5220/5140/5240, etc.:
66 1. STC_VERSION 2.16 or higher of the KMF test suite.
67 2. Snv_123 or newer of Nevada.
68 3. The TCG option must be enabled in the BIOS (x86) or ILOM pre-boot
69 environment (sun4v) of systems with a TPM device before installing
70 OS snv_123 or newer. Moreover, for sun4v system, a latest firmware
71 is required to be installed to enable TPM functionalities,
72 4. SUNWtpm, SUNWtss, SUNWtss-root may be installed. They can be found at:
73
74 SUNWtpm - /ws/onnv-gate/packages/$(uname -p)/snv_*{-nd}
75 SUNWtss & SUNWtss-root - /ws/sfwnv-gate/packages/$(uname -p)/sfwnv_*-{nd}
76
77 After installing SUNWtpm, a "reboot -- -r" may be required if /dev/tpm is
78 not attached.
79 5. After installing required packages, the 'tcsd' service must be enabled and
80 running. If not, enable it via "svcadm enable -s tcsd".
81 6. TPM device must be owned. Check via "/usr/bin/tpmadm status", if not owned,
82 issue the "tpmadm init" command and set the owner password to "87654321".
83 7. The PKCS#11 TPM token pkcs11_tpm.so must be installed. Check via
84 "/usr/sbin/cryptoadm list -p | grep pkcs11_tpm.so", if not installed, install
85 it via "cryptoadm install provider=/usr/lib/security/\$ISA/pkcs11_tpm.so"
86
87 The requirements 1, 2 & 3 are prerequisite while 4, 5, 6 & 7 are optional as
88 they can be done automatically during Solaris installation and stf_configure.
89 For step 6, if owned, before stf_configure, the variable TPM_OWNER_SECRET must
90 be exported and set to the TPM owner password, which was specified when the TPM
91 was initialized. Otherwise, it will cause execution failure due to
92 authentication error of incorrect owner password.
93
94 The test suite needs 'root' user access to the local system and may
95 ask for the system root password to be provided for this.
96
97 Access to an external HTTP URL (and, depending on your network
98 and access to an HTTP proxy server) may be required for running
99 the "kmf_download_cert" and "kmf_download_crl" tests. See the
100 NOTES section for details.
101
102
103 3. TEST SUITE INSTALLATION AND EXECUTION
104
105 As stated previously, this suite uses the STF harness. The following
106 packages are required to run this test:
107 SUNWstc-stf: the STF harness and test tools
108 SUNWstc-checkenv: the checkenv environment checking tool
109 SUNWstc-security-kmf: this test suite
110
111 In addition, the SFWexpct (expect tool) package may be optionally
112 installed on the system (NOTE: as of snv_84, expect is installed in
113 /opt/sfw/bin by default and by far expect is installed in /usr/bin by default).
114 Before snv_122, there is a bug in /usr/bin/expect that cause
115 $CODEMGR_WS/usr/src/suites/security/kmf/tests/pktool/pktool_077 to fail due to
116 timeout, see CR 6870647.
117
118
119 3.1 Installing Test Suite and Tools Packages
120
121 To install the test suite (and the tools it depends on), first remove
122 any existing installation of the test suite or tools from the system
123 and then install the new ones. For example,
124
125 root# pkgrm SUNWstc-stf SUNWstc-checkenv SUNWstc-security-kmf
126 root# pkgadd -d <package-location> SUNWstc-stf
127 root# pkgadd -d <package-location> SUNWstc-checkenv
128 root# pkgadd -d <package-location> SUNWstc-security-kmf
129
130 where <package-location> refers to the PATH where the respective
131 packages reside. The packages will be installed under /opt/<package-name>.
132
133 3.2 Configuring the Test System to Run the Test Suite
134
135 Before any tests can be executed, the target test system must first be
136 configured to run the test suite. To do this, add the STF tools to your
137 PATH, tell STF where to find the checkenv tool, and run stf_configure.
138 All this must be done as a non-root user. For example,
139
140 $ export PATH=/opt/SUNWstc-stf/bin/`uname -p`:$PATH
141 $ export STF_CHECKENV_PATH=/opt/SUNWstc-checkenv
142 $ stf_configure
143
144 If you are prompted for the system root password, it MUST be provided,
145 or the configuration step will not succeed.
146
147 Depending on your network, you may additionally need to set and export
148 all the environment variables described in the NOTES section below.
149 These environment variables may be set in any one of the methods
150 supported by stf_configure. See the STF User's Guide for details.
151
152 3.3 Executing Tests and Examining Results
153
154 To execute the tests, the 'stf_configure' step must have passed without
155 error. Once again, as a non-root user, add STF tools to your PATH, and
156 tell STF where to find checkenv. Then invoke stf_execute. For example,
157
158 $ export PATH=/opt/SUNWstc-stf/bin/`uname -p`:$PATH
159 $ export STF_CHECKENV_PATH=/opt/SUNWstc-checkenv
160 $ stf_execute
161
162 Normally this test suite is finished in about 50 minutes on Sun-Fire-V240.
163 But on systems with a TPM device, e.g. T5120 (sun4v), it will take about
164 more than 4 hours to finish executing the test suite in all modes (tpm:sparc
165 tpm:sparcv9 sparc sparcv9). In order to let test suite run on these systems,
166 we add tpm:* modes and test cases $CODEMGR_WS/usr/src/suites/security/kmf/
167 tests/pktool/pktool_{079, 080, 081 & 082}.ksh that only run in tpm:* modes.
168 The pktool_081 may take about a long time to finish in tpm:* modes so we
169 reset variable STF_TIMEOUT from 600s(default) to 1800s in $CODEMGR_WS/usr/src/
170 suites/security/kmf/config.vars in case it be killed by STF due to timeout.
171
172 Overrideable configuration variables provided in the stf_configure phase
173 may be overridden using 'stf_execute -c'. For details of the '-c'
174 option and more, see the STF User's Guide.
175
176 Test results will be placed at /var/tmp/SUNWstc-security-kmf/results.
177 Detailed journaling output is placed in files named "journal.*" in the
178 results directory (see the STF User's Guide on how to override journal
179 file or results directory names). stf_execute also prints execution
180 status summary to the terminal whence it was invoked.
181
182 The stf_filter utility can be used to see a summary of test results,
183 like so:
184
185 $ stf_filter <journal_file_name>
186
187 The output from stf_filter is a two column list of executed test cases
188 and their final result upon completion.
189
190 3.4 Building Test Binaries from Source Code
191
192 Executing tests using precompiled test suite packages is the method we
193 strongly recommend. However, if, for some reason, you need to build
194 test suite binaries from source, simply do the following:
195
196 . Install STF
197 . Obtain the test suite source
198 . Invoke stf_build followed by stf_build package
199
200 (a) Install STF
201
202 Install the precompiled STF package.
203
204 root# pkgrm SUNWstc-stf
205 root# pkgadd -d <package-location> SUNWstc-stf
206
207 where <package-location> is the location of the SUNWstc-stf package.
208 While it is possible to build STF also from source code, describing
209 that is beyond the scope of this README.
210
211 (b) Obtain the Test Suite Source
212
213 Obtain the test suite source using source code management commands
214 (TeamWare, Hg, ...) or by other methods such as extracting a tarball,
215 exploding a cpio file, etc. The example below assumes that TeamWare
216 is used and that the test suite source code resides in a workspace
217 named "/gates/stcnv-gate"
218
219 $ workspace create `pwd`/kmftest
220 $ workspace parent -p /gates/stcnv-gate -w `pwd`/kmftest
221 $ cd kmftest
222 $ bringover usr/src/suites/security/kmf
223
224 (c) Build Test Suite Binaries
225
226 $ umask 0 # optional, recommended
227 $ export PATH=/opt/SUNWstc-stf/bin/`uname -p`:$PATH
228 $ cd usr/src/suites/security/kmf
229 $ stf_build
230 ...
231 ... (many lines of 'make' and shell output ensue)
232 ...
233
234 The above command, if successful, will build the KMF test suite's
235 'proto' directory.
236
237 $ stf_build package
238
239 This will build the package supported by the current machine's system
240 architecure (i.e., if building on an x64 system, packages relevant to
241 the "i386" architecture will be built.)
242
243 Once the test suite package has been built, install the package as
244 indicated in the preceding section(s) and execute tests as described.
245
246
247 4. TEST COVERAGE
248
249 The KMF project provides a single programming interface, a unified set
250 of administrative tools, and a policy enforcement system on PKCS#11, NSS
251 and OpenSSL keystore.
252
253 This test suite covers following KMF library tests on PKCS#11, NSS and
254 OpenSSL keystore:
255 - Positive tests of KMF library key-, certficiate-, crl-, csr- and
256 policy-related APIs. Tests in this category are located at
257 tests/kmf_api/kmf_positive
258 - Multi-threaded stress tests of the KMF library. Tests in this
259 category are located at tests/kmf_api/kmf_stress
260 - Negative tests of all KMF APIs. Tests in this category are located
261 at tests/kmf_api/kmf_* (i.e., all subdirectories of tests/kmf_api,
262 kmf_positive and kmf_stress)
263
264 This test suite covers following usage of the pktool(1) command:
265 - listing all visible PKCS#11 and NSS tokens
266 - setting the passphrase to the PKCS#11 or NSS token
267 - generating public keypairs and self-signed certificates
268 - generating an asymmetric keypair and a CSR file
269 - generating symmetric keys
270 - listing certificates, keys and CRLs
271 - deleting certificates, keys and CRLs
272 - importing certificates, keys and CRLs
273 - exporting PKCS12, pem or der files that contain certificates or keys
274 - downloading certificates or CRLs from a webbased services
275 - Initialize a PKCS11 token
276 - displaying help information
277 Tests in this category are located under tests/pktool
278
279 This test suite covers following usage of the kmfcfg(1) command:
280 - listing policies
281 - deleting policies
282 - creating policies
283 - modifying policies
284 - importing policies
285 - exporting policies
286 - displaying help information
287 - pluggability configure
288 Tests in this category are located under tests/kmfcfg
289
290
291 5. NOTES
292
293 The kmf_download_cert and kmf_download_crl tests (under tests/kmf_api)
294 are designed to download certificate/crl files from an external HTTP URI.
295 This test suite provides a default URI to be used by these tests, but if
296 these defaults are not appropriate for the system under test, the
297 kmf_download_cert and kmf_download_crl tests will fail. If this happens,
298 set the following variables and re-run stf_configure:
299
300 . KMF_CERTURI -- URI whence to download certificates
301 . KMF_CRLURI -- URI whence to download crls
302 . KMF_PROXY_SET -- whether a proxy server is required. It's required if
303 your test system can't directly connect to URI specified
304 by KMF_CERTURI & KMF_CRLURI.
305 . KMF_PROXY -- proxy server. Makes sense only if KMF_PROXY_SET is set
306 . KMF_PROXY_PORT -- proxy port. Makes sense only if KMF_PROXY_SET
307 is set and KMF_PROXY is non-null.
308
309 For example:
310 $ export KMF_PROXY_SET=1
311 $ export KMF_PROXY=<the name of proxy server in format like www.proxy.com>
312 $ export KMF_PROXY_PORT=8080
313
314 These variables may also be set during the stf_execute step using the
315 '-c' switch. See the STF User's Guide for details.
316
317 8. CONTACT US
318
319 If you want to contact us, please e-mail the STC_CONTACT listed in the
320 STC.INFO. Your feedback is greatly appreciated. To file a bug or an
321 RFE against the suite, please use the stc/security/kmf subcategory.
322