diff options
Diffstat (limited to 'src/lib/libcrypto/doc/engine.pod')
-rw-r--r-- | src/lib/libcrypto/doc/engine.pod | 599 |
1 files changed, 0 insertions, 599 deletions
diff --git a/src/lib/libcrypto/doc/engine.pod b/src/lib/libcrypto/doc/engine.pod deleted file mode 100644 index 31035af398..0000000000 --- a/src/lib/libcrypto/doc/engine.pod +++ /dev/null | |||
@@ -1,599 +0,0 @@ | |||
1 | =pod | ||
2 | |||
3 | =head1 NAME | ||
4 | |||
5 | ENGINE_add, ENGINE_by_id, ENGINE_finish, ENGINE_get_first, | ||
6 | ENGINE_get_last, ENGINE_get_next, ENGINE_get_prev, | ||
7 | ENGINE_init, ENGINE_load_builtin_engines, ENGINE_remove | ||
8 | - ENGINE cryptographic module support | ||
9 | |||
10 | =head1 SYNOPSIS | ||
11 | |||
12 | #include <openssl/engine.h> | ||
13 | |||
14 | ENGINE *ENGINE_get_first(void); | ||
15 | ENGINE *ENGINE_get_last(void); | ||
16 | ENGINE *ENGINE_get_next(ENGINE *e); | ||
17 | ENGINE *ENGINE_get_prev(ENGINE *e); | ||
18 | |||
19 | int ENGINE_add(ENGINE *e); | ||
20 | int ENGINE_remove(ENGINE *e); | ||
21 | |||
22 | ENGINE *ENGINE_by_id(const char *id); | ||
23 | |||
24 | int ENGINE_init(ENGINE *e); | ||
25 | int ENGINE_finish(ENGINE *e); | ||
26 | |||
27 | void ENGINE_load_openssl(void); | ||
28 | void ENGINE_load_dynamic(void); | ||
29 | void ENGINE_load_cryptodev(void); | ||
30 | void ENGINE_load_builtin_engines(void); | ||
31 | |||
32 | void ENGINE_cleanup(void); | ||
33 | |||
34 | ENGINE *ENGINE_get_default_RSA(void); | ||
35 | ENGINE *ENGINE_get_default_DSA(void); | ||
36 | ENGINE *ENGINE_get_default_ECDH(void); | ||
37 | ENGINE *ENGINE_get_default_ECDSA(void); | ||
38 | ENGINE *ENGINE_get_default_DH(void); | ||
39 | ENGINE *ENGINE_get_default_RAND(void); | ||
40 | ENGINE *ENGINE_get_cipher_engine(int nid); | ||
41 | ENGINE *ENGINE_get_digest_engine(int nid); | ||
42 | |||
43 | int ENGINE_set_default_RSA(ENGINE *e); | ||
44 | int ENGINE_set_default_DSA(ENGINE *e); | ||
45 | int ENGINE_set_default_ECDH(ENGINE *e); | ||
46 | int ENGINE_set_default_ECDSA(ENGINE *e); | ||
47 | int ENGINE_set_default_DH(ENGINE *e); | ||
48 | int ENGINE_set_default_RAND(ENGINE *e); | ||
49 | int ENGINE_set_default_ciphers(ENGINE *e); | ||
50 | int ENGINE_set_default_digests(ENGINE *e); | ||
51 | int ENGINE_set_default_string(ENGINE *e, const char *list); | ||
52 | |||
53 | int ENGINE_set_default(ENGINE *e, unsigned int flags); | ||
54 | |||
55 | unsigned int ENGINE_get_table_flags(void); | ||
56 | void ENGINE_set_table_flags(unsigned int flags); | ||
57 | |||
58 | int ENGINE_register_RSA(ENGINE *e); | ||
59 | void ENGINE_unregister_RSA(ENGINE *e); | ||
60 | void ENGINE_register_all_RSA(void); | ||
61 | int ENGINE_register_DSA(ENGINE *e); | ||
62 | void ENGINE_unregister_DSA(ENGINE *e); | ||
63 | void ENGINE_register_all_DSA(void); | ||
64 | int ENGINE_register_ECDH(ENGINE *e); | ||
65 | void ENGINE_unregister_ECDH(ENGINE *e); | ||
66 | void ENGINE_register_all_ECDH(void); | ||
67 | int ENGINE_register_ECDSA(ENGINE *e); | ||
68 | void ENGINE_unregister_ECDSA(ENGINE *e); | ||
69 | void ENGINE_register_all_ECDSA(void); | ||
70 | int ENGINE_register_DH(ENGINE *e); | ||
71 | void ENGINE_unregister_DH(ENGINE *e); | ||
72 | void ENGINE_register_all_DH(void); | ||
73 | int ENGINE_register_RAND(ENGINE *e); | ||
74 | void ENGINE_unregister_RAND(ENGINE *e); | ||
75 | void ENGINE_register_all_RAND(void); | ||
76 | int ENGINE_register_STORE(ENGINE *e); | ||
77 | void ENGINE_unregister_STORE(ENGINE *e); | ||
78 | void ENGINE_register_all_STORE(void); | ||
79 | int ENGINE_register_ciphers(ENGINE *e); | ||
80 | void ENGINE_unregister_ciphers(ENGINE *e); | ||
81 | void ENGINE_register_all_ciphers(void); | ||
82 | int ENGINE_register_digests(ENGINE *e); | ||
83 | void ENGINE_unregister_digests(ENGINE *e); | ||
84 | void ENGINE_register_all_digests(void); | ||
85 | int ENGINE_register_complete(ENGINE *e); | ||
86 | int ENGINE_register_all_complete(void); | ||
87 | |||
88 | int ENGINE_ctrl(ENGINE *e, int cmd, long i, void *p, void (*f)(void)); | ||
89 | int ENGINE_cmd_is_executable(ENGINE *e, int cmd); | ||
90 | int ENGINE_ctrl_cmd(ENGINE *e, const char *cmd_name, | ||
91 | long i, void *p, void (*f)(void), int cmd_optional); | ||
92 | int ENGINE_ctrl_cmd_string(ENGINE *e, const char *cmd_name, const char *arg, | ||
93 | int cmd_optional); | ||
94 | |||
95 | int ENGINE_set_ex_data(ENGINE *e, int idx, void *arg); | ||
96 | void *ENGINE_get_ex_data(const ENGINE *e, int idx); | ||
97 | |||
98 | int ENGINE_get_ex_new_index(long argl, void *argp, CRYPTO_EX_new *new_func, | ||
99 | CRYPTO_EX_dup *dup_func, CRYPTO_EX_free *free_func); | ||
100 | |||
101 | ENGINE *ENGINE_new(void); | ||
102 | int ENGINE_free(ENGINE *e); | ||
103 | int ENGINE_up_ref(ENGINE *e); | ||
104 | |||
105 | int ENGINE_set_id(ENGINE *e, const char *id); | ||
106 | int ENGINE_set_name(ENGINE *e, const char *name); | ||
107 | int ENGINE_set_RSA(ENGINE *e, const RSA_METHOD *rsa_meth); | ||
108 | int ENGINE_set_DSA(ENGINE *e, const DSA_METHOD *dsa_meth); | ||
109 | int ENGINE_set_ECDH(ENGINE *e, const ECDH_METHOD *dh_meth); | ||
110 | int ENGINE_set_ECDSA(ENGINE *e, const ECDSA_METHOD *dh_meth); | ||
111 | int ENGINE_set_DH(ENGINE *e, const DH_METHOD *dh_meth); | ||
112 | int ENGINE_set_RAND(ENGINE *e, const RAND_METHOD *rand_meth); | ||
113 | int ENGINE_set_STORE(ENGINE *e, const STORE_METHOD *rand_meth); | ||
114 | int ENGINE_set_destroy_function(ENGINE *e, ENGINE_GEN_INT_FUNC_PTR destroy_f); | ||
115 | int ENGINE_set_init_function(ENGINE *e, ENGINE_GEN_INT_FUNC_PTR init_f); | ||
116 | int ENGINE_set_finish_function(ENGINE *e, ENGINE_GEN_INT_FUNC_PTR finish_f); | ||
117 | int ENGINE_set_ctrl_function(ENGINE *e, ENGINE_CTRL_FUNC_PTR ctrl_f); | ||
118 | int ENGINE_set_load_privkey_function(ENGINE *e, ENGINE_LOAD_KEY_PTR loadpriv_f); | ||
119 | int ENGINE_set_load_pubkey_function(ENGINE *e, ENGINE_LOAD_KEY_PTR loadpub_f); | ||
120 | int ENGINE_set_ciphers(ENGINE *e, ENGINE_CIPHERS_PTR f); | ||
121 | int ENGINE_set_digests(ENGINE *e, ENGINE_DIGESTS_PTR f); | ||
122 | int ENGINE_set_flags(ENGINE *e, int flags); | ||
123 | int ENGINE_set_cmd_defns(ENGINE *e, const ENGINE_CMD_DEFN *defns); | ||
124 | |||
125 | const char *ENGINE_get_id(const ENGINE *e); | ||
126 | const char *ENGINE_get_name(const ENGINE *e); | ||
127 | const RSA_METHOD *ENGINE_get_RSA(const ENGINE *e); | ||
128 | const DSA_METHOD *ENGINE_get_DSA(const ENGINE *e); | ||
129 | const ECDH_METHOD *ENGINE_get_ECDH(const ENGINE *e); | ||
130 | const ECDSA_METHOD *ENGINE_get_ECDSA(const ENGINE *e); | ||
131 | const DH_METHOD *ENGINE_get_DH(const ENGINE *e); | ||
132 | const RAND_METHOD *ENGINE_get_RAND(const ENGINE *e); | ||
133 | const STORE_METHOD *ENGINE_get_STORE(const ENGINE *e); | ||
134 | ENGINE_GEN_INT_FUNC_PTR ENGINE_get_destroy_function(const ENGINE *e); | ||
135 | ENGINE_GEN_INT_FUNC_PTR ENGINE_get_init_function(const ENGINE *e); | ||
136 | ENGINE_GEN_INT_FUNC_PTR ENGINE_get_finish_function(const ENGINE *e); | ||
137 | ENGINE_CTRL_FUNC_PTR ENGINE_get_ctrl_function(const ENGINE *e); | ||
138 | ENGINE_LOAD_KEY_PTR ENGINE_get_load_privkey_function(const ENGINE *e); | ||
139 | ENGINE_LOAD_KEY_PTR ENGINE_get_load_pubkey_function(const ENGINE *e); | ||
140 | ENGINE_CIPHERS_PTR ENGINE_get_ciphers(const ENGINE *e); | ||
141 | ENGINE_DIGESTS_PTR ENGINE_get_digests(const ENGINE *e); | ||
142 | const EVP_CIPHER *ENGINE_get_cipher(ENGINE *e, int nid); | ||
143 | const EVP_MD *ENGINE_get_digest(ENGINE *e, int nid); | ||
144 | int ENGINE_get_flags(const ENGINE *e); | ||
145 | const ENGINE_CMD_DEFN *ENGINE_get_cmd_defns(const ENGINE *e); | ||
146 | |||
147 | EVP_PKEY *ENGINE_load_private_key(ENGINE *e, const char *key_id, | ||
148 | UI_METHOD *ui_method, void *callback_data); | ||
149 | EVP_PKEY *ENGINE_load_public_key(ENGINE *e, const char *key_id, | ||
150 | UI_METHOD *ui_method, void *callback_data); | ||
151 | |||
152 | void ENGINE_add_conf_module(void); | ||
153 | |||
154 | =head1 DESCRIPTION | ||
155 | |||
156 | These functions create, manipulate, and use cryptographic modules in the | ||
157 | form of B<ENGINE> objects. These objects act as containers for | ||
158 | implementations of cryptographic algorithms, and support a | ||
159 | reference-counted mechanism to allow them to be dynamically loaded in and | ||
160 | out of the running application. | ||
161 | |||
162 | The cryptographic functionality that can be provided by an B<ENGINE> | ||
163 | implementation includes the following abstractions; | ||
164 | |||
165 | RSA_METHOD - for providing alternative RSA implementations | ||
166 | DSA_METHOD, DH_METHOD, RAND_METHOD, ECDH_METHOD, ECDSA_METHOD, | ||
167 | STORE_METHOD - similarly for other OpenSSL APIs | ||
168 | EVP_CIPHER - potentially multiple cipher algorithms (indexed by 'nid') | ||
169 | EVP_DIGEST - potentially multiple hash algorithms (indexed by 'nid') | ||
170 | key-loading - loading public and/or private EVP_PKEY keys | ||
171 | |||
172 | =head2 Reference counting and handles | ||
173 | |||
174 | Due to the modular nature of the ENGINE API, pointers to ENGINEs need to be | ||
175 | treated as handles - ie. not only as pointers, but also as references to | ||
176 | the underlying ENGINE object. Ie. one should obtain a new reference when | ||
177 | making copies of an ENGINE pointer if the copies will be used (and | ||
178 | released) independently. | ||
179 | |||
180 | ENGINE objects have two levels of reference-counting to match the way in | ||
181 | which the objects are used. At the most basic level, each ENGINE pointer is | ||
182 | inherently a B<structural> reference - a structural reference is required | ||
183 | to use the pointer value at all, as this kind of reference is a guarantee | ||
184 | that the structure can not be deallocated until the reference is released. | ||
185 | |||
186 | However, a structural reference provides no guarantee that the ENGINE is | ||
187 | initialised and able to use any of its cryptographic | ||
188 | implementations. Indeed it's quite possible that most ENGINEs will not | ||
189 | initialise at all in typical environments, as ENGINEs are typically used to | ||
190 | support specialised hardware. To use an ENGINE's functionality, you need a | ||
191 | B<functional> reference. This kind of reference can be considered a | ||
192 | specialised form of structural reference, because each functional reference | ||
193 | implicitly contains a structural reference as well - however to avoid | ||
194 | difficult-to-find programming bugs, it is recommended to treat the two | ||
195 | kinds of reference independently. If you have a functional reference to an | ||
196 | ENGINE, you have a guarantee that the ENGINE has been initialised ready to | ||
197 | perform cryptographic operations and will remain uninitialised | ||
198 | until after you have released your reference. | ||
199 | |||
200 | I<Structural references> | ||
201 | |||
202 | This basic type of reference is used for instantiating new ENGINEs, | ||
203 | iterating across OpenSSL's internal linked-list of loaded | ||
204 | ENGINEs, reading information about an ENGINE, etc. Essentially a structural | ||
205 | reference is sufficient if you only need to query or manipulate the data of | ||
206 | an ENGINE implementation rather than use its functionality. | ||
207 | |||
208 | The ENGINE_new() function returns a structural reference to a new (empty) | ||
209 | ENGINE object. There are other ENGINE API functions that return structural | ||
210 | references such as; ENGINE_by_id(), ENGINE_get_first(), ENGINE_get_last(), | ||
211 | ENGINE_get_next(), ENGINE_get_prev(). All structural references should be | ||
212 | released by a corresponding to call to the ENGINE_free() function - the | ||
213 | ENGINE object itself will only actually be cleaned up and deallocated when | ||
214 | the last structural reference is released. | ||
215 | |||
216 | It should also be noted that many ENGINE API function calls that accept a | ||
217 | structural reference will internally obtain another reference - typically | ||
218 | this happens whenever the supplied ENGINE will be needed by OpenSSL after | ||
219 | the function has returned. Eg. the function to add a new ENGINE to | ||
220 | OpenSSL's internal list is ENGINE_add() - if this function returns success, | ||
221 | then OpenSSL will have stored a new structural reference internally so the | ||
222 | caller is still responsible for freeing their own reference with | ||
223 | ENGINE_free() when they are finished with it. In a similar way, some | ||
224 | functions will automatically release the structural reference passed to it | ||
225 | if part of the function's job is to do so. Eg. the ENGINE_get_next() and | ||
226 | ENGINE_get_prev() functions are used for iterating across the internal | ||
227 | ENGINE list - they will return a new structural reference to the next (or | ||
228 | previous) ENGINE in the list or NULL if at the end (or beginning) of the | ||
229 | list, but in either case the structural reference passed to the function is | ||
230 | released on behalf of the caller. | ||
231 | |||
232 | To clarify a particular function's handling of references, one should | ||
233 | always consult that function's documentation "man" page, or failing that | ||
234 | the openssl/engine.h header file includes some hints. | ||
235 | |||
236 | I<Functional references> | ||
237 | |||
238 | As mentioned, functional references exist when the cryptographic | ||
239 | functionality of an ENGINE is required to be available. A functional | ||
240 | reference can be obtained in one of two ways; from an existing structural | ||
241 | reference to the required ENGINE, or by asking OpenSSL for the default | ||
242 | operational ENGINE for a given cryptographic purpose. | ||
243 | |||
244 | To obtain a functional reference from an existing structural reference, | ||
245 | call the ENGINE_init() function. This returns zero if the ENGINE was not | ||
246 | already operational and couldn't be successfully initialised (eg. lack of | ||
247 | system drivers, no special hardware attached, etc), otherwise it will | ||
248 | return non-zero to indicate that the ENGINE is now operational and will | ||
249 | have allocated a new B<functional> reference to the ENGINE. All functional | ||
250 | references are released by calling ENGINE_finish() (which removes the | ||
251 | implicit structural reference as well). | ||
252 | |||
253 | The second way to get a functional reference is by asking OpenSSL for a | ||
254 | default implementation for a given task, eg. by ENGINE_get_default_RSA(), | ||
255 | ENGINE_get_default_cipher_engine(), etc. These are discussed in the next | ||
256 | section, though they are not usually required by application programmers as | ||
257 | they are used automatically when creating and using the relevant | ||
258 | algorithm-specific types in OpenSSL, such as RSA, DSA, EVP_CIPHER_CTX, etc. | ||
259 | |||
260 | =head2 Default implementations | ||
261 | |||
262 | For each supported abstraction, the ENGINE code maintains an internal table | ||
263 | of state to control which implementations are available for a given | ||
264 | abstraction and which should be used by default. These implementations are | ||
265 | registered in the tables and indexed by an 'nid' value, because | ||
266 | abstractions like EVP_CIPHER and EVP_DIGEST support many distinct | ||
267 | algorithms and modes, and ENGINEs can support arbitrarily many of them. | ||
268 | In the case of other abstractions like RSA, DSA, etc, there is only one | ||
269 | "algorithm" so all implementations implicitly register using the same 'nid' | ||
270 | index. | ||
271 | |||
272 | When a default ENGINE is requested for a given abstraction/algorithm/mode, (eg. | ||
273 | when calling RSA_new_method(NULL)), a "get_default" call will be made to the | ||
274 | ENGINE subsystem to process the corresponding state table and return a | ||
275 | functional reference to an initialised ENGINE whose implementation should be | ||
276 | used. If no ENGINE should (or can) be used, it will return NULL and the caller | ||
277 | will operate with a NULL ENGINE handle - this usually equates to using the | ||
278 | conventional software implementation. In the latter case, OpenSSL will from | ||
279 | then on behave the way it used to before the ENGINE API existed. | ||
280 | |||
281 | Each state table has a flag to note whether it has processed this | ||
282 | "get_default" query since the table was last modified, because to process | ||
283 | this question it must iterate across all the registered ENGINEs in the | ||
284 | table trying to initialise each of them in turn, in case one of them is | ||
285 | operational. If it returns a functional reference to an ENGINE, it will | ||
286 | also cache another reference to speed up processing future queries (without | ||
287 | needing to iterate across the table). Likewise, it will cache a NULL | ||
288 | response if no ENGINE was available so that future queries won't repeat the | ||
289 | same iteration unless the state table changes. This behaviour can also be | ||
290 | changed; if the ENGINE_TABLE_FLAG_NOINIT flag is set (using | ||
291 | ENGINE_set_table_flags()), no attempted initialisations will take place, | ||
292 | instead the only way for the state table to return a non-NULL ENGINE to the | ||
293 | "get_default" query will be if one is expressly set in the table. Eg. | ||
294 | ENGINE_set_default_RSA() does the same job as ENGINE_register_RSA() except | ||
295 | that it also sets the state table's cached response for the "get_default" | ||
296 | query. In the case of abstractions like EVP_CIPHER, where implementations are | ||
297 | indexed by 'nid', these flags and cached-responses are distinct for each 'nid' | ||
298 | value. | ||
299 | |||
300 | =head2 Application requirements | ||
301 | |||
302 | This section will explain the basic things an application programmer should | ||
303 | support to make the most useful elements of the ENGINE functionality | ||
304 | available to the user. The first thing to consider is whether the | ||
305 | programmer wishes to make alternative ENGINE modules available to the | ||
306 | application and user. OpenSSL maintains an internal linked list of | ||
307 | "visible" ENGINEs from which it has to operate - at start-up, this list is | ||
308 | empty and in fact if an application does not call any ENGINE API calls and | ||
309 | it uses static linking against openssl, then the resulting application | ||
310 | binary will not contain any alternative ENGINE code at all. So the first | ||
311 | consideration is whether any/all available ENGINE implementations should be | ||
312 | made visible to OpenSSL - this is controlled by calling the various "load" | ||
313 | functions, eg. | ||
314 | |||
315 | /* Make ALL ENGINE implementations bundled with OpenSSL available */ | ||
316 | ENGINE_load_builtin_engines(); | ||
317 | |||
318 | Note that ENGINE_load_dynamic(void) is a placeholder and does not enable | ||
319 | dynamic engine loading support. | ||
320 | |||
321 | Having called any of these functions, ENGINE objects would have been | ||
322 | dynamically allocated and populated with these implementations and linked | ||
323 | into OpenSSL's internal linked list. At this point it is important to | ||
324 | mention an important API function; | ||
325 | |||
326 | void ENGINE_cleanup(void); | ||
327 | |||
328 | If no ENGINE API functions are called at all in an application, then there | ||
329 | are no inherent memory leaks to worry about from the ENGINE functionality, | ||
330 | however if any ENGINEs are loaded, even if they are never registered or | ||
331 | used, it is necessary to use the ENGINE_cleanup() function to | ||
332 | correspondingly cleanup before program exit, if the caller wishes to avoid | ||
333 | memory leaks. This mechanism uses an internal callback registration table | ||
334 | so that any ENGINE API functionality that knows it requires cleanup can | ||
335 | register its cleanup details to be called during ENGINE_cleanup(). This | ||
336 | approach allows ENGINE_cleanup() to clean up after any ENGINE functionality | ||
337 | at all that your program uses, yet doesn't automatically create linker | ||
338 | dependencies to all possible ENGINE functionality - only the cleanup | ||
339 | callbacks required by the functionality you do use will be required by the | ||
340 | linker. | ||
341 | |||
342 | The fact that ENGINEs are made visible to OpenSSL (and thus are linked into | ||
343 | the program and loaded into memory at run-time) does not mean they are | ||
344 | "registered" or called into use by OpenSSL automatically - that behaviour | ||
345 | is something for the application to control. Some applications | ||
346 | will want to allow the user to specify exactly which ENGINE they want used | ||
347 | if any is to be used at all. Others may prefer to load all support and have | ||
348 | OpenSSL automatically use at run-time any ENGINE that is able to | ||
349 | successfully initialise - ie. to assume that this corresponds to | ||
350 | acceleration hardware attached to the machine or some such thing. There are | ||
351 | probably numerous other ways in which applications may prefer to handle | ||
352 | things, so we will simply illustrate the consequences as they apply to a | ||
353 | couple of simple cases and leave developers to consider these and the | ||
354 | source code to openssl's builtin utilities as guides. | ||
355 | |||
356 | I<Using a specific ENGINE implementation> | ||
357 | |||
358 | Here we'll assume an application has been configured by its user or admin | ||
359 | to want to use the "ACME" ENGINE if it is available in the version of | ||
360 | OpenSSL the application was compiled with. If it is available, it should be | ||
361 | used by default for all RSA, DSA, and symmetric cipher operation, otherwise | ||
362 | OpenSSL should use its builtin software as per usual. The following code | ||
363 | illustrates how to approach this; | ||
364 | |||
365 | ENGINE *e; | ||
366 | const char *engine_id = "ACME"; | ||
367 | ENGINE_load_builtin_engines(); | ||
368 | e = ENGINE_by_id(engine_id); | ||
369 | if (!e) | ||
370 | /* the engine isn't available */ | ||
371 | return; | ||
372 | if (!ENGINE_init(e)) { | ||
373 | /* the engine couldn't initialise, release 'e' */ | ||
374 | ENGINE_free(e); | ||
375 | return; | ||
376 | } | ||
377 | if (!ENGINE_set_default_RSA(e)) | ||
378 | /* This should only happen when 'e' can't initialise, but the previous | ||
379 | * statement suggests it did. */ | ||
380 | abort(); | ||
381 | ENGINE_set_default_DSA(e); | ||
382 | ENGINE_set_default_ciphers(e); | ||
383 | /* Release the functional reference from ENGINE_init() */ | ||
384 | ENGINE_finish(e); | ||
385 | /* Release the structural reference from ENGINE_by_id() */ | ||
386 | ENGINE_free(e); | ||
387 | |||
388 | I<Automatically using builtin ENGINE implementations> | ||
389 | |||
390 | Here we'll assume we want to load and register all ENGINE implementations | ||
391 | bundled with OpenSSL, such that for any cryptographic algorithm required by | ||
392 | OpenSSL - if there is an ENGINE that implements it and can be initialise, | ||
393 | it should be used. The following code illustrates how this can work; | ||
394 | |||
395 | /* Load all bundled ENGINEs into memory and make them visible */ | ||
396 | ENGINE_load_builtin_engines(); | ||
397 | /* Register all of them for every algorithm they collectively implement */ | ||
398 | ENGINE_register_all_complete(); | ||
399 | |||
400 | That's all that's required. Eg. the next time OpenSSL tries to set up an | ||
401 | RSA key, any bundled ENGINEs that implement RSA_METHOD will be passed to | ||
402 | ENGINE_init() and if any of those succeed, that ENGINE will be set as the | ||
403 | default for RSA use from then on. | ||
404 | |||
405 | =head2 Advanced configuration support | ||
406 | |||
407 | There is a mechanism supported by the ENGINE framework that allows each | ||
408 | ENGINE implementation to define an arbitrary set of configuration | ||
409 | "commands" and expose them to OpenSSL and any applications based on | ||
410 | OpenSSL. This mechanism is entirely based on the use of name-value pairs | ||
411 | and assumes ASCII input (no unicode or UTF for now!), so it is ideal if | ||
412 | applications want to provide a transparent way for users to provide | ||
413 | arbitrary configuration "directives" directly to such ENGINEs. It is also | ||
414 | possible for the application to dynamically interrogate the loaded ENGINE | ||
415 | implementations for the names, descriptions, and input flags of their | ||
416 | available "control commands", providing a more flexible configuration | ||
417 | scheme. However, if the user is expected to know which ENGINE device he/she | ||
418 | is using (in the case of specialised hardware, this goes without saying) | ||
419 | then applications may not need to concern themselves with discovering the | ||
420 | supported control commands and simply prefer to pass settings into ENGINEs | ||
421 | exactly as they are provided by the user. | ||
422 | |||
423 | Before illustrating how control commands work, it is worth mentioning what | ||
424 | they are typically used for. Broadly speaking there are two uses for | ||
425 | control commands; the first is to provide the necessary details to the | ||
426 | implementation (which may know nothing at all specific to the host system) | ||
427 | so that it can be initialised for use. This could include the path to any | ||
428 | driver or config files it needs to load, required network addresses, | ||
429 | smart-card identifiers, passwords to initialise protected devices, | ||
430 | logging information, etc etc. This class of commands typically needs to be | ||
431 | passed to an ENGINE B<before> attempting to initialise it, ie. before | ||
432 | calling ENGINE_init(). The other class of commands consist of settings or | ||
433 | operations that tweak certain behaviour or cause certain operations to take | ||
434 | place, and these commands may work either before or after ENGINE_init(), or | ||
435 | in some cases both. ENGINE implementations should provide indications of | ||
436 | this in the descriptions attached to builtin control commands and/or in | ||
437 | external product documentation. | ||
438 | |||
439 | I<Issuing control commands to an ENGINE> | ||
440 | |||
441 | Let's illustrate by example; a function for which the caller supplies the | ||
442 | name of the ENGINE it wishes to use, a table of string-pairs for use before | ||
443 | initialisation, and another table for use after initialisation. Note that | ||
444 | the string-pairs used for control commands consist of a command "name" | ||
445 | followed by the command "parameter" - the parameter could be NULL in some | ||
446 | cases but the name can not. This function should initialise the ENGINE | ||
447 | (issuing the "pre" commands beforehand and the "post" commands afterwards) | ||
448 | and set it as the default for everything except RAND and then return a | ||
449 | boolean success or failure. | ||
450 | |||
451 | int | ||
452 | generic_load_engine_fn(const char *engine_id, | ||
453 | const char **pre_cmds, int pre_num, | ||
454 | const char **post_cmds, int post_num) | ||
455 | { | ||
456 | ENGINE *e = ENGINE_by_id(engine_id); | ||
457 | |||
458 | if (!e) | ||
459 | return 0; | ||
460 | while (pre_num--) { | ||
461 | if (!ENGINE_ctrl_cmd_string(e, | ||
462 | pre_cmds[0], pre_cmds[1], 0)) { | ||
463 | fprintf(stderr, | ||
464 | "Failed command (%s - %s:%s)\n", | ||
465 | engine_id, pre_cmds[0], | ||
466 | pre_cmds[1] ? pre_cmds[1] : "(NULL)"); | ||
467 | ENGINE_free(e); | ||
468 | return 0; | ||
469 | } | ||
470 | pre_cmds += 2; | ||
471 | } | ||
472 | if (!ENGINE_init(e)) { | ||
473 | fprintf(stderr, "Failed initialisation\n"); | ||
474 | ENGINE_free(e); | ||
475 | return 0; | ||
476 | } | ||
477 | /* | ||
478 | * ENGINE_init() returned a functional reference, | ||
479 | * so free the structural reference from | ||
480 | * ENGINE_by_id(). | ||
481 | */ | ||
482 | ENGINE_free(e); | ||
483 | while (post_num--) { | ||
484 | if (!ENGINE_ctrl_cmd_string(e, | ||
485 | post_cmds[0], post_cmds[1], 0)) { | ||
486 | fprintf(stderr, | ||
487 | "Failed command (%s - %s:%s)\n", | ||
488 | engine_id, post_cmds[0], | ||
489 | post_cmds[1] ? post_cmds[1] : "(NULL)"); | ||
490 | ENGINE_finish(e); | ||
491 | return 0; | ||
492 | } | ||
493 | post_cmds += 2; | ||
494 | } | ||
495 | ENGINE_set_default(e, ENGINE_METHOD_ALL & ~ENGINE_METHOD_RAND); | ||
496 | /* Success */ | ||
497 | return 1; | ||
498 | } | ||
499 | |||
500 | Note that ENGINE_ctrl_cmd_string() accepts a boolean argument that can | ||
501 | relax the semantics of the function - if set non-zero it will only return | ||
502 | failure if the ENGINE supported the given command name but failed while | ||
503 | executing it, if the ENGINE doesn't support the command name it will simply | ||
504 | return success without doing anything. In this case we assume the user is | ||
505 | only supplying commands specific to the given ENGINE so we set this to | ||
506 | FALSE. | ||
507 | |||
508 | I<Discovering supported control commands> | ||
509 | |||
510 | It is possible to discover at run-time the names, numerical-ids, descriptions | ||
511 | and input parameters of the control commands supported by an ENGINE using a | ||
512 | structural reference. Note that some control commands are defined by OpenSSL | ||
513 | itself and it will intercept and handle these control commands on behalf of the | ||
514 | ENGINE, ie. the ENGINE's ctrl() handler is not used for the control command. | ||
515 | openssl/engine.h defines an index, ENGINE_CMD_BASE, that all control commands | ||
516 | implemented by ENGINEs should be numbered from. Any command value lower than | ||
517 | this symbol is considered a "generic" command is handled directly by the | ||
518 | OpenSSL core routines. | ||
519 | |||
520 | It is using these "core" control commands that one can discover the control | ||
521 | commands implemented by a given ENGINE, specifically the commands; | ||
522 | |||
523 | #define ENGINE_HAS_CTRL_FUNCTION 10 | ||
524 | #define ENGINE_CTRL_GET_FIRST_CMD_TYPE 11 | ||
525 | #define ENGINE_CTRL_GET_NEXT_CMD_TYPE 12 | ||
526 | #define ENGINE_CTRL_GET_CMD_FROM_NAME 13 | ||
527 | #define ENGINE_CTRL_GET_NAME_LEN_FROM_CMD 14 | ||
528 | #define ENGINE_CTRL_GET_NAME_FROM_CMD 15 | ||
529 | #define ENGINE_CTRL_GET_DESC_LEN_FROM_CMD 16 | ||
530 | #define ENGINE_CTRL_GET_DESC_FROM_CMD 17 | ||
531 | #define ENGINE_CTRL_GET_CMD_FLAGS 18 | ||
532 | |||
533 | Whilst these commands are automatically processed by the OpenSSL framework code, | ||
534 | they use various properties exposed by each ENGINE to process these | ||
535 | queries. An ENGINE has 3 properties it exposes that can affect how this behaves; | ||
536 | it can supply a ctrl() handler, it can specify ENGINE_FLAGS_MANUAL_CMD_CTRL in | ||
537 | the ENGINE's flags, and it can expose an array of control command descriptions. | ||
538 | If an ENGINE specifies the ENGINE_FLAGS_MANUAL_CMD_CTRL flag, then it will | ||
539 | simply pass all these "core" control commands directly to the ENGINE's ctrl() | ||
540 | handler (and thus, it must have supplied one), so it is up to the ENGINE to | ||
541 | reply to these "discovery" commands itself. If that flag is not set, then the | ||
542 | OpenSSL framework code will work with the following rules; | ||
543 | |||
544 | if no ctrl() handler supplied; | ||
545 | ENGINE_HAS_CTRL_FUNCTION returns FALSE (zero), | ||
546 | all other commands fail. | ||
547 | if a ctrl() handler was supplied but no array of control commands; | ||
548 | ENGINE_HAS_CTRL_FUNCTION returns TRUE, | ||
549 | all other commands fail. | ||
550 | if a ctrl() handler and array of control commands was supplied; | ||
551 | ENGINE_HAS_CTRL_FUNCTION returns TRUE, | ||
552 | all other commands proceed processing ... | ||
553 | |||
554 | If the ENGINE's array of control commands is empty then all other commands will | ||
555 | fail, otherwise; ENGINE_CTRL_GET_FIRST_CMD_TYPE returns the identifier of | ||
556 | the first command supported by the ENGINE, ENGINE_GET_NEXT_CMD_TYPE takes the | ||
557 | identifier of a command supported by the ENGINE and returns the next command | ||
558 | identifier or fails if there are no more, ENGINE_CMD_FROM_NAME takes a string | ||
559 | name for a command and returns the corresponding identifier or fails if no such | ||
560 | command name exists, and the remaining commands take a command identifier and | ||
561 | return properties of the corresponding commands. All except | ||
562 | ENGINE_CTRL_GET_FLAGS return the string length of a command name or description, | ||
563 | or populate a supplied character buffer with a copy of the command name or | ||
564 | description. ENGINE_CTRL_GET_FLAGS returns a bitwise-OR'd mask of the following | ||
565 | possible values; | ||
566 | |||
567 | #define ENGINE_CMD_FLAG_NUMERIC (unsigned int)0x0001 | ||
568 | #define ENGINE_CMD_FLAG_STRING (unsigned int)0x0002 | ||
569 | #define ENGINE_CMD_FLAG_NO_INPUT (unsigned int)0x0004 | ||
570 | #define ENGINE_CMD_FLAG_INTERNAL (unsigned int)0x0008 | ||
571 | |||
572 | If the ENGINE_CMD_FLAG_INTERNAL flag is set, then any other flags are purely | ||
573 | informational to the caller - this flag will prevent the command being usable | ||
574 | for any higher-level ENGINE functions such as ENGINE_ctrl_cmd_string(). | ||
575 | "INTERNAL" commands are not intended to be exposed to text-based configuration | ||
576 | by applications, administrations, users, etc. These can support arbitrary | ||
577 | operations via ENGINE_ctrl(), including passing to and/or from the control | ||
578 | commands data of any arbitrary type. These commands are supported in the | ||
579 | discovery mechanisms simply allow applications to determine if an ENGINE | ||
580 | supports certain specific commands it might want to use (eg. application "foo" | ||
581 | might query various ENGINEs to see if they implement "FOO_GET_VENDOR_LOGO_GIF" - | ||
582 | and ENGINE could therefore decide whether or not to support this "foo"-specific | ||
583 | extension). | ||
584 | |||
585 | =head2 Future developments | ||
586 | |||
587 | The ENGINE API and internal architecture is currently being reviewed. Slated for | ||
588 | possible release in 0.9.8 is support for transparent loading of "dynamic" | ||
589 | ENGINEs (built as self-contained shared-libraries). This would allow ENGINE | ||
590 | implementations to be provided independently of OpenSSL libraries and/or | ||
591 | OpenSSL-based applications, and would also remove any requirement for | ||
592 | applications to explicitly use the "dynamic" ENGINE to bind to shared-library | ||
593 | implementations. | ||
594 | |||
595 | =head1 SEE ALSO | ||
596 | |||
597 | L<rsa(3)|rsa(3)>, L<dsa(3)|dsa(3)>, L<dh(3)|dh(3)>, L<rand(3)|rand(3)> | ||
598 | |||
599 | =cut | ||