[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [V3 PATCH 1/1] virtio-crypto: introduce akcipher service
On Thu, Jan 20, 2022 at 05:48:09AM +0000, Gonglei (Arei) wrote:
>
>
> > -----Original Message-----
> > From: Michael S. Tsirkin [mailto:mst@redhat.com]
> > Sent: Wednesday, January 19, 2022 11:17 PM
> > To: äç <helei.sig11@bytedance.com>
> > Cc: virtio-comment@lists.oasis-open.org; pizhenwei@bytedance.com;
> > xin.zeng@intel.com; Gonglei (Arei) <arei.gonglei@huawei.com>
> > Subject: Re: [V3 PATCH 1/1] virtio-crypto: introduce akcipher service
> >
> > On Tue, Jan 11, 2022 at 11:14:27AM +0800, äç wrote:
> > > Hello virtio community,
> > >
> > > Iâd like to request the TC vote on resolving the follow issue:
> > > Enhancement: https://github.com/oasis-tcs/virtio-spec/issues/129
> >
> > Does not look like we have a lot of response with this, and it seems risky to add
> > this now since spec freeze is imminent.
> > I think the right way to do it is to submit the supporting patches to the linux
> > kernel and probably qemu.
> > A bunch of crypto experts on the linux mailing list.
> >
> > In particular I note that virtio crypto already has a ton of features that don't seem
> > to be supported by the linux driver or qemu. Kind of reluctant to add more
> > without some review from developers implementing this.
> >
> >
> Hi Michael,
>
> I can't agree more with you. Eg. the virtio crypto doesn't support stateless mode currently in linux and
> qemu upstream lthough this virtio crypto spec already supports. If we expand the specification in firstly,
> it may make it more difficult to maintain in the future.
>
> Regards,
> -Gonglei
So what's the plan with stateless btw? why isn't it used? is it
completely useless? why do we have it in the spec?
> > > > On Dec 10, 2021, at 8:53 PM, Lei He <helei.sig11@bytedance.com> wrote:
> > > >
> > > > Introduce akcipher (asymmetric key cipher) service type, several
> > > > asymmetric algorithms and relevent information:
> > > > - RSA(padding algorithm, ASN.1 schema definition)
> > > > - ECDSA(ECC algorithm)
> > > >
> > > > Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
> > > > Signed-off-by: Lei He <helei.sig11@bytedance.com>
> > > > ---
> > > > introduction.tex | 12 +++
> > > > virtio-crypto.tex | 317
> > > > +++++++++++++++++++++++++++++++++++++++++++++++++++++-
> > > > 2 files changed, 325 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/introduction.tex b/introduction.tex index
> > > > 6d52717..92a6911 100644
> > > > --- a/introduction.tex
> > > > +++ b/introduction.tex
> > > > @@ -79,6 +79,18 @@ \section{Normative References}\label{sec:Normative
> > References}
> > > > \phantomsection\label{intro:SCMI}\textbf{[SCMI]} &
> > > > Arm System Control and Management Interface, DEN0056,
> > > > \newline\url{https://developer.arm.com/docs/den0056/c}, version C
> > > > and any future revisions\\
> > > > + \phantomsection\label{intro:rfc3447}\textbf{[RFC3447]} &
> > > > + J. Jonsson.,``Public-Key Cryptography Standards (PKCS) \#1: RSA
> > Cryptography'', February 2003.
> > > > + \newline\url{https://www.ietf.org/rfc/rfc3447.txt}\\
> > > > + \phantomsection\label{intro:NIST}\textbf{[FIPS186-3]} &
> > > > + National Institute of Standards and Technology (NIST), FIPS Publication
> > 180-3: Secure Hash Standard, October 2008.
> > > > +
> > \newline\url{https://csrc.nist.gov/csrc/media/publications/fips/186/3/archi
> > ve/2009-06-25/documents/fips_186-3.pdf}\\
> > > > + \phantomsection\label{intro:rfc6025}\textbf{[RFC6025]} &
> > > > + C.Wallace., ``ASN.1 Translation'', October 2010.
> > > > + \newline\url{https://www.ietf.org/rfc/rfc6025.txt}\\
> > > > + \phantomsection\label{intro:rfc3279}\textbf{[RFC3279]} &
> > > > + W.Polk., ``Algorithms and Identifiers for the Internet X.509 Public Key
> > Infrastructure Certificate and Certificate Revocation List (CRL) Profile'', April 2002.
> > > > + \newline\url{https://www.ietf.org/rfc/rfc3279.txt}\\
> > > >
> > > > \end{longtable}
> > > >
> > > > diff --git a/virtio-crypto.tex b/virtio-crypto.tex index
> > > > 74746f9..256c144 100644
> > > > --- a/virtio-crypto.tex
> > > > +++ b/virtio-crypto.tex
> > > > @@ -2,7 +2,7 @@ \section{Crypto Device}\label{sec:Device Types /
> > > > Crypto Device}
> > > >
> > > > The virtio crypto device is a virtual cryptography device as well as
> > > > a virtual cryptographic accelerator. The virtio crypto device
> > > > provides the -following crypto services: CIPHER, MAC, HASH, and
> > > > AEAD. Virtio crypto
> > > > +following crypto services: CIPHER, MAC, HASH, AEAD and AKCIPHER.
> > > > +Virtio crypto
> > > > devices have a single control queue and at least one data queue.
> > > > Crypto operation requests are placed into a data queue, and serviced
> > > > by the device. Some crypto operation requests are only valid in the
> > > > context of a @@ -39,6 +39,8 @@ \subsection{Feature bits}\label{sec:Device
> > Types / Crypto Device / Feature bits}
> > > > supported by the MAC service.
> > > > \item VIRTIO_CRYPTO_F_AEAD_STATELESS_MODE (4) stateless mode
> > requests are
> > > > supported by the AEAD service.
> > > > +\item VIRTIO_CRYPTO_F_AKCIPHER_STATELESS_MODE (5) stateless mode
> > requests are
> > > > + supported by the AKCIPHER service.
> > > > \end{description}
> > > >
> > > >
> > > > @@ -52,6 +54,7 @@ \subsubsection{Feature bit
> > > > requirements}\label{sec:Device Types / Crypto Device
> > \item[VIRTIO_CRYPTO_F_HASH_STATELESS_MODE] Requires
> > VIRTIO_CRYPTO_F_REVISION_1.
> > > > \item[VIRTIO_CRYPTO_F_MAC_STATELESS_MODE] Requires
> > VIRTIO_CRYPTO_F_REVISION_1.
> > > > \item[VIRTIO_CRYPTO_F_AEAD_STATELESS_MODE] Requires
> > VIRTIO_CRYPTO_F_REVISION_1.
> > > > +\item[VIRTIO_CRYPTO_F_AKCIPHER_STATELESS_MODE] Requires
> > VIRTIO_CRYPTO_F_REVISION_1.
> > > > \end{description}
> > > >
> > > > \subsection{Supported crypto services}\label{sec:Device Types /
> > > > Crypto Device / Supported crypto services} @@ -59,7 +62,7 @@
> > > > \subsection{Supported crypto services}\label{sec:Device Types / Crypto
> > Device / The following crypto services are defined:
> > > >
> > > > \begin{lstlisting}
> > > > -/* CIPHER service */
> > > > +/* CIPHER (Symmetric Key Cipher) service */
> > > > #define VIRTIO_CRYPTO_SERVICE_CIPHER 0
> > > > /* HASH service */
> > > > #define VIRTIO_CRYPTO_SERVICE_HASH 1
> > > > @@ -67,6 +70,8 @@ \subsection{Supported crypto services}\label{sec:Device
> > Types / Crypto Device /
> > > > #define VIRTIO_CRYPTO_SERVICE_MAC 2
> > > > /* AEAD (Authenticated Encryption with Associated Data) service */
> > > > #define VIRTIO_CRYPTO_SERVICE_AEAD 3
> > > > +/* AKCIPHER (Asymmetric Key Cipher) service */ #define
> > > > +VIRTIO_CRYPTO_SERVICE_AKCIPHER 4
> > > > \end{lstlisting}
> > > >
> > > > The above constants designate bits used to indicate the which of
> > > > crypto services are @@ -181,6 +186,24 @@ \subsubsection{AEAD
> > > > services}\label{sec:Device Types / Crypto Device / Supported operation
> > requests, see \ref{sec:Device Types / Crypto Device / Device Operation / Control
> > Virtqueue / Session operation}.
> > > > \end{enumerate}
> > > >
> > > > +\subsubsection{AKCIPHER services}\label{sec: Device Types / Crypto
> > > > +Device / Supported crypto services / AKCIPHER services}
> > > > +
> > > > +The following AKCIPHER algorithms are defined:
> > > > +\begin{lstlisting}
> > > > +#define VIRTIO_CRYPTO_NO_AKCIPHER 0
> > > > +#define VIRTIO_CRYPTO_AKCIPHER_RSA 1
> > > > +#define VIRTIO_CRYPTO_AKCIPHER_ECDSA 2 \end{lstlisting}
> > > > +
> > > > +The above constants have two usages:
> > > > +\begin{enumerate}
> > > > +\item As bit numbers, used to tell the driver which AKCIPHER
> > > > +algorithms are supported by the device, see \ref{sec:Device Types / Crypto
> > Device / Device configuration layout}.
> > > > +\item As values, used to designate the algorithm in asymmetric
> > > > +crypto operation requests, see \ref{sec:Device Types / Crypto Device /
> > Device Operation / Control Virtqueue / Session operation}.
> > > > +\end{enumerate}
> > > > +
> > > > +
> > > > \subsection{Device configuration layout}\label{sec:Device Types /
> > > > Crypto Device / Device configuration layout}
> > > >
> > > > Crypto device configuration uses the following layout structure:
> > > > @@ -204,6 +227,7 @@ \subsection{Device configuration
> > layout}\label{sec:Device Types / Crypto Device
> > > > le32 reserved;
> > > > /* Maximum size of each crypto request's content in bytes */
> > > > le64 max_size;
> > > > + le32 akcipher_algo;
> > > > };
> > > > \end{lstlisting}
> > > >
> > > > @@ -241,6 +265,7 @@ \subsection{Device configuration
> > > > layout}\label{sec:Device Types / Crypto Device
> > > >
> > > > \item [\field{max_size}] is the maximum size of the variable-length
> > parameters of
> > > > data operation of each crypto request's content supported by the
> > device.
> > > > +\item [\field{akcipher_algo}] AKCIPHER algorithms bit 0-31, see \ref{sec:
> > Device Types / Crypto Device / Supported crypto services / AKCIPHER services}.
> > > > \end{description}
> > > >
> > > > \begin{note}
> > > > @@ -323,6 +348,7 @@ \subsubsection{Operation Status}\label{sec:Device
> > Types / Crypto Device / Device
> > > > VIRTIO_CRYPTO_NOTSUPP = 3,
> > > > VIRTIO_CRYPTO_INVSESS = 4,
> > > > VIRTIO_CRYPTO_NOSPC = 5,
> > > > + VIRTIO_CRYPTO_KEY_REJECTED = 6,
> > > > VIRTIO_CRYPTO_MAX
> > > > };
> > > > \end{lstlisting}
> > > > @@ -334,6 +360,7 @@ \subsubsection{Operation
> > > > Status}\label{sec:Device Types / Crypto Device / Device \item
> > VIRTIO_CRYPTO_INVSESS: invalid session ID when executing crypto operations.
> > > > \item VIRTIO_CRYPTO_NOSPC: no free session ID (only when the
> > VIRTIO_CRYPTO_F_REVISION_1
> > > > feature bit is negotiated).
> > > > +\item VIRTIO_CRYPTO_KEY_REJECTED: signature verification failed (only
> > when AKCIPHER verification).
> > > > \item VIRTIO_CRYPTO_ERR: any failure not mentioned above occurs.
> > > > \end{itemize*}
> > > >
> > > > @@ -364,6 +391,10 @@ \subsubsection{Control Virtqueue}\label{sec:Device
> > Types / Crypto Device / Devic
> > > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x02)
> > > > #define VIRTIO_CRYPTO_AEAD_DESTROY_SESSION \
> > > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x03)
> > > > +#define VIRTIO_CRYPTO_AKCIPHER_CREATE_SESSION \
> > > > + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AKCIPHER,
> > 0x04)
> > > > +#define VIRTIO_CRYPTO_AKCIPHER_DESTROY_SESSION \
> > > > + VIRTIO_CRYPTO_OPCDE(VIRTIO_CRYPTO_SERVICE_AKCIPHER,
> > 0x05)
> > > > le32 opcode;
> > > > /* algo should be service-specific algorithms */
> > > > le32 algo;
> > > > @@ -427,6 +458,11 @@ \subsubsection{Control Virtqueue}\label{sec:Device
> > Types / Crypto Device / Devic
> > > > VIRTIO_CRYPTO_F_REVISION_1 is negotiated and struct
> > virtio_crypto_aead_create_session_flf is
> > > > padded to 56 bytes if NOT negotiated, and \field{op_vlf} is struct
> > > > virtio_crypto_aead_create_session_vlf.
> > > > +\item If the opcode (in \field{header}) is
> > VIRTIO_CRYPTO_AKCIPHER_CREATE_SESSION
> > > > + then \field{op_flf} is struct virtio_crypto_akcipher_create_session_flf if
> > > > + VIRTIO_CRYPTO_F_REVISION_1 is negotiated and struct
> > virtio_crypto_akcipher_create_session_flf is
> > > > + padded to 56 bytes if NOT negotiated, and \field{op_vlf} is struct
> > > > + virtio_crypto_akcipher_create_session_vlf.
> > > > \item If the opcode (in \field{header}) is
> > VIRTIO_CRYPTO_CIPHER_DESTROY_SESSION
> > > > or VIRTIO_CRYPTO_HASH_DESTROY_SESSION or
> > VIRTIO_CRYPTO_MAC_DESTROY_SESSION or
> > > > VIRTIO_CRYPTO_AEAD_DESTROY_SESSION then \field{op_flf} is struct
> > > > @@ -690,12 +726,137 @@ \subsubsection{Control
> > > > Virtqueue}\label{sec:Device Types / Crypto Device / Devic The length
> > > > of \field{key} is specified in \field{key_len} in struct
> > virtio_crypto_aead_create_session_flf.
> > > >
> > > > +\subparagraph{Session operation: AKCIPHER session}\label{sec:Device
> > > > +Types / Crypto Device / Device Operation / Control Virtqueue /
> > > > +Session operation / Session operation: AKCIPHER session}
> > > > +
> > > > +Due to the complexity of asymmetric key algorithms, different
> > > > +algorithms require different parameters. The following data
> > > > +structures are used as supplementary parameters to describe the
> > asymmetric algorithm sessions.
> > > > +
> > > > +For the RSA algorithm, the extra parameters are as follows:
> > > > +\begin{lstlisting}
> > > > +struct virtio_crypto_rsa_session_para {
> > > > +#define VIRTIO_CRYPTO_RSA_RAW_PADDING 0
> > > > +#define VIRTIO_CRYPTO_RSA_PKCS1_PADDING 1
> > > > + le32 padding_algo;
> > > > +
> > > > +#define VIRTIO_CRYPTO_RSA_NO_HASH 0
> > > > +#define VIRTIO_CRYPTO_RSA_MD2 1
> > > > +#define VIRTIO_CRYPTO_RSA_MD3 2
> > > > +#define VIRTIO_CRYPTO_RSA_MD4 3
> > > > +#define VIRTIO_CRYPTO_RSA_MD5 4
> > > > +#define VIRTIO_CRYPTO_RSA_SHA1 5
> > > > +#define VIRTIO_CRYPTO_RSA_SHA256 6
> > > > +#define VIRTIO_CRYPTO_RSA_SHA384 7
> > > > +#define VIRTIO_CRYPTO_RSA_SHA512 8
> > > > +#define VIRTIO_CRYPTO_RSA_SHA224 9
> > > > + le32 hash_algo;
> > > > +};
> > > > +\end{lstlisting}
> > > > +
> > > > +\field{padding_algo} specifies the padding method used by RSA sessions.
> > > > +\begin{itemize*}
> > > > +\item If VIRTIO_CRYPTO_RSA_RAW_PADDING is specified, 1)
> > > > +\field{hash_algo} is ignored, 2) ciphertext and plaintext MUST be
> > > > +padded with leading zeros,
> > > > +3) and RSA sessions with VIRTIO_CRYPTO_RSA_RAW_PADDING MUST not
> > be
> > > > +used for verification and signing operations.
> > > > +\item If VIRTIO_CRYPTO_RSA_PKCS1_PADDING is specified,
> > > > +EMSA-PKCS1-v1_5 padding method is used(see
> > > > +\hyperref[intro:rfc3447]{PKCS\#1}), \field{hash_algo} specifies how the
> > digest of the data passed to RSA sessions is calculated when verifying and signing.
> > > > +It only affects the padding algorithm and is ignored during encryption and
> > decryption.
> > > > +\end{itemize*}
> > > > +
> > > > +The ECC algorithms such as the ECDSA algorithm, cannot use custom
> > > > +curves, only the following known curves can be used(see
> > > > +\hyperref[intro:NIST]{NIST-recommended curves})
> > > > +
> > > > +\begin{lstlisting}
> > > > +#define VIRTIO_CRYPTO_CURVE_UNKNOWN 0
> > > > +#define VIRTIO_CRYPTO_CURVE_NIST_P192 1 #define
> > > > +VIRTIO_CRYPTO_CURVE_NIST_P224 2 #define
> > > > +VIRTIO_CRYPTO_CURVE_NIST_P256 3 #define
> > > > +VIRTIO_CRYPTO_CURVE_NIST_P384 4 #define
> > > > +VIRTIO_CRYPTO_CURVE_NIST_P521 5 \end{lstlisting}
> > > > +
> > > > +For the ECDSA algorithm, the extra parameters are as follows:
> > > > +\begin{lstlisting}
> > > > +struct virtio_crypto_ecdsa_session_para {
> > > > + /* See VIRTIO_CRYPTO_CURVE_* above */
> > > > + le32 curve_id;
> > > > +};
> > > > +\end{lstlisting}
> > > > +
> > > > +The fixed-length and the variable-length parameters of AKCIPHER session
> > requests are as follows:
> > > > +\begin{lstlisting}
> > > > +struct virtio_crypto_akcipher_create_session_flf {
> > > > + /* Device read only portion */
> > > > +
> > > > + /* See VIRTIO_CRYPTO_AKCIPHER_* above */
> > > > + le32 algo;
> > > > +#define VIRTIO_CRYPTO_AKCIPHER_KEY_TYPE_PUBLIC 1 #define
> > > > +VIRTIO_CRYPTO_AKCIPHER_KEY_TYPE_PRIVATE 2
> > > > + le32 key_type;
> > > > + /* length of key */
> > > > + le32 key_len;
> > > > +
> > > > +#define VIRTIO_CRYPTO_AKCIPHER_SESS_ALGO_SPEC_HDR_SIZE 44
> > > > + u8 algo_flf[VIRTIO_CRYPTO_AKCIPHER_SESS_ALGO_SPEC_HDR_SIZE];
> > > > +};
> > > > +
> > > > +struct virtio_crypto_akcipher_create_session_vlf {
> > > > + /* Device read only portion */
> > > > + u8 key[key_len];
> > > > +};
> > > > +\end{lstlisting}
> > > > +
> > > > +\field{algo} decides the type used by \field{algo_flf}.
> > > > +\field{algo_flf} is fixed to 44 bytes and MUST contains of be one
> > > > +the following structures:
> > > > +\begin{itemize*}
> > > > +\item struct virtio_crypto_rsa_session_para \item struct
> > > > +virtio_crypto_ecdsa_session_para \end{itemize*}
> > > > +
> > > > +The length of \field{key} is specified in \field{key_len} in the
> > > > +struct virtio_crypto_akcipher_create_session_flf.
> > > > +
> > > > +If the key of an asymmetric algorithm contains multiple fields, for
> > > > +example, the RSA key pairs, they MUST be described using the
> > > > +ASN.1 structure and MUST be DER encoded (see
> > \hyperref[intro:rfc6025]{rfc6025}).
> > > > +If the key of an asymmetric algorithm only contains an integer
> > > > +field, for example, the ECDSA private key, then MUST be encoded
> > > > +with I2OSP primitives described in \hyperref[intro:rfc3447]{PKCS\#1}.
> > > > +
> > > > +The schema of RSA keys is described with the RSAPrivateKey and
> > > > +RSAPublicKey structure defined in \hyperref[intro:rfc3447]{PKCS\#1}.
> > > > +
> > > > +\begin{lstlisting}
> > > > +RsaPrivateKey ::= SEQUENCE {
> > > > + version INTEGER
> > > > + modulus INTEGER
> > > > + publicExponent INTEGER
> > > > + privateExponent INTEGER
> > > > + prime1 INTEGER
> > > > + prime2 INTEGER
> > > > + exponent1 INTEGER
> > > > + exponent1 INTEGER
> > > > + coefficient INTEGER
> > > > +}
> > > > +
> > > > +RsaPublicKey ::= SEQUENCE {
> > > > + modulus INTEGER
> > > > + publicExponent INTEGER
> > > > +}
> > > > +\end{lstlisting}
> > > > +
> > > > +The length of \field{key} is specified in \field{key_len} in struct
> > > > +virtio_crypto_akcipher_create_session_flf.
> > > >
> > > > \drivernormative{\subparagraph}{Session operation: create
> > > > session}{Device Types / Crypto Device / Device Operation / Control
> > > > Virtqueue / Session operation / Session operation: create session}
> > > >
> > > > \begin{itemize*}
> > > > -\item The driver MUST set the \field{opcode} field based on service type:
> > CIPHER, HASH, MAC, or AEAD.
> > > > +\item The driver MUST set the \field{opcode} field based on service type:
> > CIPHER, HASH, MAC, AEAD or AKCIPHER.
> > > > \item The driver MUST set the control general header, the opcode specific
> > header,
> > > > the opcode specific extra parameters and the opcode specific outcome
> > buffer in turn.
> > > > See \ref{sec:Device Types / Crypto Device / Device Operation / Control
> > Virtqueue}.
> > > > @@ -726,7 +887,7 @@ \subsubsection{Control
> > > > Virtqueue}\label{sec:Device Types / Crypto Device / Devic Operation
> > > > / Control Virtqueue / Session operation / Session operation: destroy
> > > > session}
> > > >
> > > > \begin{itemize*}
> > > > -\item The driver MUST set the \field{opcode} field based on service type:
> > CIPHER, HASH, MAC, or AEAD.
> > > > +\item The driver MUST set the \field{opcode} field based on service type:
> > CIPHER, HASH, MAC, AEAD or AKCIPHER.
> > > > \item The driver MUST set the \field{session_id} to a valid value assigned by
> > the device
> > > > when the session was created.
> > > > \end{itemize*}
> > > > @@ -764,6 +925,14 @@ \subsubsection{Data Virtqueue}\label{sec:Device
> > Types / Crypto Device / Device O
> > > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x00)
> > #define
> > > > VIRTIO_CRYPTO_AEAD_DECRYPT \
> > > > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x01)
> > > > +#define VIRTIO_CRYPTO_AKCIPHER_ENCRYPT \
> > > > + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AKCIPHER, 0x00)
> > > > +#define VIRTIO_CRYPTO_AKCIPHER_DECRYPT \
> > > > + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AKCIPHER, 0x01)
> > > > +#define VIRTIO_CRYPTO_AKCIPHER_SIGN \
> > > > + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AKCIPHER, 0x02)
> > > > +#define VIRTIO_CRYPTO_AKCIPHER_VERIFY \
> > > > + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AKCIPHER, 0x03)
> > > > le32 opcode;
> > > > /* algo should be service-specific algorithms */
> > > > le32 algo;
> > > > @@ -857,6 +1026,17 @@ \subsubsection{Data Virtqueue}\label{sec:Device
> > Types / Crypto Device / Device O
> > > > and struct virtio_crypto_aead_data_flf is padded to 48 bytes if NOT
> > negotiated,
> > > > and \field{op_vlf} is struct virtio_crypto_aead_data_vlf.
> > > > \end{itemize*}
> > > > +\item If the opcode (in \field{header}) is
> > VIRTIO_CRYPTO_AKCIPHER_ENCRYPT, VIRTIO_CRYPTO_AKCIPHER_DECRYPT,
> > > > + VIRTIO_CRYPTO_AKCIPHER_SIGN or
> > VIRTIO_CRYPTO_AKCIPHER_VERIFY then:
> > > > + \begin{itemize*}
> > > > + \item If VIRTIO_CRYPTO_F_AKCIPHER_STATELESS_MODE is negotiated,
> > \field{op_flf} is
> > > > + struct virtio_crypto_akcipher_data_flf_statless, and \field{op_vlf}
> > is struct
> > > > + virtio_crypto_akcipher_data_vlf_stateless.
> > > > + \item If VIRTIO_CRYPTO_F_AKCIPHER_STATELESS_MODE is NOT
> > negotiated, \field{op_flf}
> > > > + is struct virtio_crypto_akcipher_data_flf if
> > VIRTIO_CRYPTO_F_REVISION_1 is negotiated
> > > > + and struct virtio_crypto_akcipher_data_flf is padded to 48 bytes if
> > NOT negotiated,
> > > > + and \field{op_vlf} is struct virtio_crypto_akcipher_data_vlf.
> > > > + \end{itemize*}
> > > > \end{itemize*}
> > > >
> > > > \field{inhdr} is a unified input header that used to return the
> > > > status of @@ -1533,3 +1713,132 @@ \subsubsection{AEAD Service
> > > > Operation}\label{sec:Device Types / Crypto Device / \item
> > VIRTIO_CRYPTO_ERR if any failure not mentioned above occurs.
> > > > \end{itemize*}
> > > > \end{itemize*}
> > > > +
> > > > +\subsubsection{AKCIPHER Service Operation}\label{sec:Device Types /
> > > > +Crypto Device / Device Operation / AKCIPHER Service Operation}
> > > > +
> > > > +Session mode AKCIPHER requests are as follows:
> > > > +
> > > > +\begin{lstlisting}
> > > > +struct virtio_crypto_akcipher_data_flf {
> > > > + /* length of source data */
> > > > + le32 src_data_len;
> > > > + /* length of dst data */
> > > > + le32 dst_data_len;
> > > > +};
> > > > +
> > > > +struct virtio_crypto_akcipher_data_vlf {
> > > > + /* Device read only portion */
> > > > + /* Source data */
> > > > + u8 src_data[src_data_len];
> > > > +
> > > > + /* Device write only portion */
> > > > + /* Pointer to output data */
> > > > + u8 dst_data[dst_data_len];
> > > > +};
> > > > +\end{lstlisting}
> > > > +
> > > > +Each data request uses the virtio_crypto_akcipher_flf structure and
> > > > +the virtio_crypto_akcipher_data_vlf structure to store information used to
> > run the AKCIPHER operations.
> > > > +
> > > > +For encryption, decryption, and signing:
> > > > +\field{src_data} is the source data that will be processed, note
> > > > +that for signing operations, src_data stores the data to be signed,
> > > > +which usually is the digest of some data rather than the data itself.
> > > > +\field{src_data_len} is the length of source data.
> > > > +\field{dst_result} is the result data and \field{dst_data_len} is the length of
> > it.
> > > > +
> > > > +For verification:
> > > > +\field{src_data_len} refers to the length of the signature, and
> > > > +\field{dst_data_len} refers to the length of signed data, where the signed
> > data is usually the digest of some data.
> > > > +\field{src_data} is spliced by the signature and the signed data,
> > > > +the src_data with the lower address stores the signature, and the higher
> > address stores the signed data.
> > > > +\field{dst_data} is always empty for verification.
> > > > +
> > > > +Different algorithms have different signature formats.
> > > > +For the RSA algorithm, the result is determined by the padding
> > > > +algorithm specified by \field{padding_algo} in structure
> > virtio_crypto_rsa_session_para.
> > > > +
> > > > +For the ECDSA algorithm, the signature is composed of the following
> > > > +ASN.1 structure(see \hyperref[intro:rfc3279]{RFC3279})
> > > > +and MUST be DER encoded.
> > > > +\begin{lstlisting}
> > > > +Ecdsa-Sig-Value ::= SEQUENCE {
> > > > + r INTEGER,
> > > > + s INTEGER
> > > > +}
> > > > +\end{lstlisting}
> > > > +
> > > > +Stateless mode AKCIPHER service requests are as follows:
> > > > +\begin{lstlisting}
> > > > +struct virtio_crypto_akcipher_data_flf_stateless {
> > > > + struct {
> > > > + /* See VIRTIO_CYRPTO_AKCIPHER* above */
> > > > + le32 algo;
> > > > + /* See VIRTIO_CRYPTO_AKCIPHER_KEY_TYPE_* above */
> > > > + le32 key_type;
> > > > + /* length of key */
> > > > + le32 key_len;
> > > > +
> > > > + /* algothrim specific parameters described above */
> > > > + union {
> > > > + struct virtio_crypto_rsa_session_para rsa;
> > > > + struct virtio_crypto_ecdsa_session_para ecdsa;
> > > > + } u;
> > > > + } sess_para;
> > > > +
> > > > + /* length of source data */
> > > > + le32 src_data_len;
> > > > + /* length of destination data */
> > > > + le32 dst_data_len;
> > > > +};
> > > > +
> > > > +struct virtio_crypto_akcipher_data_vlf_stateless {
> > > > + /* Device read only portion */
> > > > + u8 akcipher_key[key_len];
> > > > +
> > > > + /* Source data */
> > > > + u8 src_data[src_data_len];
> > > > +
> > > > + /* Device write only portion */
> > > > + u8 dst_data[dst_data_len];
> > > > +};
> > > > +\end{lstlisting}
> > > > +
> > > > +In stateless mode, the format of key and signature, the meaning of
> > > > +src_data and dst_data, are all the same with session mode.
> > > > +
> > > > +\drivernormative{\paragraph}{AKCIPHER Service Operation}{Device
> > > > +Types / Crypto Device / Device Operation / AKCIPHER Service
> > > > +Operation}
> > > > +
> > > > +\begin{itemize*}
> > > > +\item If the driver uses the session mode, then the driver MUST set
> > > > + \field{session_id} in struct virtio_crypto_op_header to a valid
> > > > + value assigned by the device when the session was created.
> > > > +\item If the VIRTIO_CRYPTO_F_AKCIPHER_STATELESS_MODE feature bit is
> > negotiated, 1) if the
> > > > + driver uses the stateless mode, then the driver MUST set the \field{flag}
> > field in
> > > > + struct virtio_crypto_op_header to ZERO and MUST set the fields in
> > struct
> > > > + virtio_crypto_akcipher_flf_stateless.sess_para, 2) if the driver uses the
> > session
> > > > + mode, then the driver MUST set the \field{flag} field in struct
> > virtio_crypto_op_header
> > > > + to VIRTIO_CRYPTO_FLAG_SESSION_MODE.
> > > > +\item The driver MUST set the \field{opcode} field in struct
> > virtio_crypto_op_header
> > > > + to one of VIRTIO_CRYPTO_AKCIPHER_ENCRYPT,
> > VIRTIO_CRYPTO_AKCIPHER_DESTROY_SESSION,
> > > > + VIRTIO_CRYPTO_AKCIPHER_SIGN, and
> > VIRTIO_CRYPTO_AKCIPHER_VERIFY.
> > > > +\end{itemize*}
> > > > +
> > > > +\devicenormative{\paragraph}{AKCIPHER Service Operation}{Device
> > > > +Types / Crypto Device / Device Operation / AKCIPHER Service
> > > > +Operation}
> > > > +
> > > > +\begin{itemize*}
> > > > +\item If the VIRTIO_CRYPTO_F_AKCIPHER_STATELESS_MODE feature bit is
> > negotiated, the
> > > > + device MUST parse the virtio_crypto_akcipher_data_vlf_stateless
> > based on the \field{opcode}
> > > > + field in general header.
> > > > +\item The device MUST copy the result of cryptographic operation in the
> > dst_data[].
> > > > +\item The device MUST set the \field{status} field in struct
> > virtio_crypto_inhdr to
> > > > + one of the following values of enum VIRTIO_CRYPTO_STATUS:
> > > > +\begin{itemize*}
> > > > +\item VIRTIO_CRYPTO_OK if the operation success.
> > > > +\item VIRTIO_CRYPTO_NOTSUPP if the requested algorithm or operation is
> > unsupported.
> > > > +\item VIRTIO_CRYPTO_BADMSG if the verification result is incorrect.
> > > > +\item VIRTIO_CRYPTO_INVSESS if the session ID invalid when in session
> > mode.
> > > > +\item VIRTIO_CRYPTO_KEY_REJECTED if the signature verification failed.
> > > > +\item VIRTIO_CRYPTO_ERR if any failure not mentioned above occurs.
> > > > +\end{itemize*}
> > > > +\end{itemize*}
> > > > --
> > > > 2.11.0
> > > >
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]