2018-02-01 17:18:17 +00:00
|
|
|
.. SPDX-License-Identifier: BSD-3-Clause
|
|
|
|
Copyright(c) 2016 Intel Corporation.
|
2016-06-20 15:40:04 +01:00
|
|
|
|
|
|
|
KASUMI Crypto Poll Mode Driver
|
|
|
|
===============================
|
|
|
|
|
|
|
|
The KASUMI PMD (**librte_pmd_kasumi**) provides poll mode crypto driver
|
|
|
|
support for utilizing Intel Libsso library, which implements F8 and F9 functions
|
|
|
|
for KASUMI UEA1 cipher and UIA1 hash algorithms.
|
|
|
|
|
|
|
|
Features
|
|
|
|
--------
|
|
|
|
|
|
|
|
KASUMI PMD has support for:
|
|
|
|
|
|
|
|
Cipher algorithm:
|
|
|
|
|
2016-09-19 12:14:52 +01:00
|
|
|
* RTE_CRYPTO_CIPHER_KASUMI_F8
|
2016-06-20 15:40:04 +01:00
|
|
|
|
|
|
|
Authentication algorithm:
|
|
|
|
|
2016-09-19 12:14:52 +01:00
|
|
|
* RTE_CRYPTO_AUTH_KASUMI_F9
|
2016-06-20 15:40:04 +01:00
|
|
|
|
|
|
|
Limitations
|
|
|
|
-----------
|
|
|
|
|
|
|
|
* Chained mbufs are not supported.
|
cryptodev: fix KASUMI F9 expected parameters
For KASUMI F9 algorithm, COUNT, FRESH and DIRECTION
input values need to be contiguous with
the message, as described in the KASUMI and QAT PMD
documentation.
Before, the COUNT and FRESH values were set
as part of the AAD (now IV), but always set before
the beginning of the message.
Since now the IV is set after the crypto operation,
it is not possible to have these values in the
expected location.
Therefore, as these are required to be contiguous,
cryptodev API will expect these them to be passed
as a single buffer, already constructed, so
authentication IV parameters not needed anymore.
Fixes: 681f540da52b ("cryptodev: do not use AAD in wireless algorithms")
Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
Acked-by: Fiona Trahe <fiona.trahe@intel.com>
2017-07-14 08:06:52 +01:00
|
|
|
* KASUMI(F9) supported only if hash offset and length field is byte-aligned.
|
2016-07-09 17:35:58 +01:00
|
|
|
* In-place bit-level operations for KASUMI(F8) are not supported
|
|
|
|
(if length and/or offset of data to be ciphered is not byte-aligned).
|
|
|
|
|
2016-06-20 15:40:04 +01:00
|
|
|
|
|
|
|
Installation
|
|
|
|
------------
|
|
|
|
|
|
|
|
To build DPDK with the KASUMI_PMD the user is required to download
|
2018-05-22 13:43:12 +01:00
|
|
|
the export controlled ``libsso_kasumi`` library, by registering in
|
|
|
|
`Intel Resource & Design Center <https://www.intel.com/content/www/us/en/design/resource-design-center.html>`_.
|
|
|
|
Once approval has been granted, the user needs to search for
|
|
|
|
*Kasumi F8 F9 3GPP cryptographic algorithms Software Library* to download the
|
|
|
|
library or directly through this `link <https://cdrdv2.intel.com/v1/dl/getContent/575866>`_.
|
2016-06-20 15:40:04 +01:00
|
|
|
After downloading the library, the user needs to unpack and compile it
|
|
|
|
on their system before building DPDK::
|
|
|
|
|
2016-10-13 20:21:53 +01:00
|
|
|
make
|
|
|
|
|
2017-07-13 06:36:50 +01:00
|
|
|
**Note**: When encrypting with KASUMI F8, by default the library
|
|
|
|
encrypts full blocks of 8 bytes, regardless the number of bytes to
|
|
|
|
be encrypted provided (which leads to a possible buffer overflow).
|
|
|
|
To avoid this situation, it is necessary not to pass
|
|
|
|
3GPP_SAFE_BUFFERS as a compilation flag.
|
|
|
|
Also, this is required when using chained operations
|
|
|
|
(cipher-then-auth/auth-then-cipher).
|
|
|
|
For this, in the Makefile of the library, make sure that this flag
|
|
|
|
is commented out::
|
|
|
|
|
|
|
|
#EXTRA_CFLAGS += -D_3GPP_SAFE_BUFFERS
|
|
|
|
|
2016-10-13 20:21:53 +01:00
|
|
|
**Note**: To build the PMD as a shared library, the libsso_kasumi
|
|
|
|
library must be built as follows::
|
|
|
|
|
|
|
|
make KASUMI_CFLAGS=-DKASUMI_C
|
|
|
|
|
2016-06-20 15:40:04 +01:00
|
|
|
|
|
|
|
Initialization
|
|
|
|
--------------
|
|
|
|
|
|
|
|
In order to enable this virtual crypto PMD, user must:
|
|
|
|
|
|
|
|
* Export the environmental variable LIBSSO_KASUMI_PATH with the path where
|
|
|
|
the library was extracted (kasumi folder).
|
|
|
|
|
|
|
|
* Build the LIBSSO library (explained in Installation section).
|
|
|
|
|
|
|
|
* Set CONFIG_RTE_LIBRTE_PMD_KASUMI=y in config/common_base.
|
|
|
|
|
|
|
|
To use the PMD in an application, user must:
|
|
|
|
|
2017-05-04 18:01:19 +02:00
|
|
|
* Call rte_vdev_init("crypto_kasumi") within the application.
|
2016-06-20 15:40:04 +01:00
|
|
|
|
2017-05-04 18:01:19 +02:00
|
|
|
* Use --vdev="crypto_kasumi" in the EAL options, which will call rte_vdev_init() internally.
|
2016-06-20 15:40:04 +01:00
|
|
|
|
|
|
|
The following parameters (all optional) can be provided in the previous two calls:
|
|
|
|
|
|
|
|
* socket_id: Specify the socket where the memory for the device is going to be allocated
|
|
|
|
(by default, socket_id will be the socket where the core that is creating the PMD is running on).
|
|
|
|
|
|
|
|
* max_nb_queue_pairs: Specify the maximum number of queue pairs in the device (8 by default).
|
|
|
|
|
|
|
|
* max_nb_sessions: Specify the maximum number of sessions that can be created (2048 by default).
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
.. code-block:: console
|
|
|
|
|
2017-07-26 01:59:59 +01:00
|
|
|
./l2fwd-crypto -l 1 -n 4 --vdev="crypto_kasumi,socket_id=0,max_nb_sessions=128" \
|
|
|
|
-- -p 1 --cdev SW --chain CIPHER_ONLY --cipher_algo "kasumi-f8"
|
cryptodev: fix KASUMI F9 expected parameters
For KASUMI F9 algorithm, COUNT, FRESH and DIRECTION
input values need to be contiguous with
the message, as described in the KASUMI and QAT PMD
documentation.
Before, the COUNT and FRESH values were set
as part of the AAD (now IV), but always set before
the beginning of the message.
Since now the IV is set after the crypto operation,
it is not possible to have these values in the
expected location.
Therefore, as these are required to be contiguous,
cryptodev API will expect these them to be passed
as a single buffer, already constructed, so
authentication IV parameters not needed anymore.
Fixes: 681f540da52b ("cryptodev: do not use AAD in wireless algorithms")
Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
Acked-by: Fiona Trahe <fiona.trahe@intel.com>
2017-07-14 08:06:52 +01:00
|
|
|
|
|
|
|
Extra notes on KASUMI F9
|
|
|
|
------------------------
|
|
|
|
|
|
|
|
When using KASUMI F9 authentication algorithm, the input buffer must be
|
|
|
|
constructed according to the 3GPP KASUMI specifications (section 4.4, page 13):
|
|
|
|
`<http://cryptome.org/3gpp/35201-900.pdf>`_.
|
|
|
|
Input buffer has to have COUNT (4 bytes), FRESH (4 bytes), MESSAGE and DIRECTION (1 bit)
|
|
|
|
concatenated. After the DIRECTION bit, a single '1' bit is appended, followed by
|
|
|
|
between 0 and 7 '0' bits, so that the total length of the buffer is multiple of 8 bits.
|
|
|
|
Note that the actual message can be any length, specified in bits.
|
|
|
|
|
|
|
|
Once this buffer is passed this way, when creating the crypto operation,
|
|
|
|
length of data to authenticate (op.sym.auth.data.length) must be the length
|
|
|
|
of all the items described above, including the padding at the end.
|
|
|
|
Also, offset of data to authenticate (op.sym.auth.data.offset)
|
|
|
|
must be such that points at the start of the COUNT bytes.
|