The present disclosure relates to a method and system for enhancing authentication and integrity of a cipher text by integrating SM2 in the transport layer of the SSH protocol.
BACKGROUND
The Secure Shell (SSH) protocol is a cryptographic network protocol for secure data communication, remote command-line login, remote command execution, and other secure network services between two networked computers that connects, via a secure channel over an insecure network between a SSH server and a SSH client. It is therefore, used for secure remote login and other secure network services over an insecure network as it ensures confidentiality and integrity of data. The SSH protocol consists of three major components:
• The Transport Layer Protocol, which provides server authentication, confidentiality, and integrity with perfect forward secrecy.
• The User Authentication Protocol, which authenticates the client to the server.
• The Connection Protocol, which multiplexes the encrypted tunnel into several logical channels.
There are many products which mandate SSH for secure remote login and other secure network services over an insecure network .Further, SSH is indispensible to the deployment of SSH File Transfer Protocol (SFTP). The subsystem of SSH (SFTP) can be deployed in large scale SSH network usage scenarios because of the performance and security benefits achieved by using SM2 algorithm.
Apart from networks, there are many products as well that support the SSH protocol and hence, require SM2 key exchange in the SSH transport protocol for its product that are deployed .
State of the art illustrates two protocols, Diffie Hellman (DH) key agreement (RFC 4253) and Elliptic Curve Diffie-Hellman (ECDH) key agreement (RFC 5656),for exchanging cryptographic keys in the SSH . DH key agreement protocol allows users to exchange a secret key over an insecure medium without any prior secrets. ECDH key exchange is an improvement based on the DH protocol which allows two parties, each having an elliptic public-private key pair, to establish a shared secret over an insecure channel. Hence, it is a variant of the Diffie–Hellman (DH)

protocol using Elliptic Curve Cryptography (ECC). ECC is an approach to public-key cryptography based on the algebraic structure of elliptic curves over finite fields. Figure 1 illustrates a flow diagram representation of the functionality of the mechanism according to prior art, more particularly in Elliptic curve Diffie-Hellman (ECDH) agreement protocol to establish a shared secret over an insecure channel.
A key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are negotiated in the transport layer protocol of the SSH between the SSH server and the SSH client. A key exchange algorithm enables the communicating users, interacting for the first time, to share a secret key over an insecure communication channel. This secret key can then be used to encrypt any subsequent communication between the two users by using a symmetric key cipher.
However, the safety and authentication of the cipher text provided by conventional art can be enhanced further. Also, the key exchange messages, algorithm complexity and the form of the data to be signed can be secured more effectively.
SUMMARY
The present disclosure relates to a method and system for enhancing authentication and integrity of a cipher text. It teaches a method of integration of SM2 in the transport layer of the SSH protocol, which enhances the security of SSH. It also enhances safety and authentication of the cipher text.
The mechanism taught by the present disclosure contains SSH supported by the SM2 method, which provides an improved process for key-exchange message, a better algorithm complexity and the form of the data to be signed.
SM2 Digital Signature Algorithm (SM2DSA) enhances the authentication of the signature compared to the ECC algorithm, as the message is hashed along with some parameters referring to signer and system.
SSH SM2 method integration is uniquely identified by its algorithm identifiers, key format, and signature encoding and method names. Following are the parameters, which help check the

breach of confidentiality and authentication in telecommunications, especially in the Chinese telecom arena:
■ SM2 Public Key Algorithms - It is specified by family of public key format identifiers.
• “sm2dsa-sha2-*” : Each identifier is a concatenation of “sm2dsa-sha2-” and identifier of the elliptic curve domain parameters.
• “sm2dsa-sm3-*” : Each identifier is a concatenation of “sm2dsa-sm3-” and identifier of the elliptic curve domain parameters.
■ Key Format - It is defined by the following family of public key formats.
• The “sm2dsa-sha2-*” key formats have the following encoding:
- string “sm2dsa-sha2-[identifier]”
- byte[n] ecc_key_blob
• The “sm2dsasm3-*” key formats have the following encoding:
- string “sm2dsa-sm3-[identifier]”
- byte[n] ecc_key_blob
■ Signature Encoding - It is defined by the following family of “sm2dsa-sha2-*” and
“sm2dsa-sm3-*” signature algorithms.
• The “sm2dsa-sha2-*” signatures have the following encoding:
- string “sm2dsa-sha2-[identifier]”
- string sm2dsa_signature_blob
• The “sm2dsa-sm32-*” signatures have the following encoding:
- string “sm2dsa-sm3-[identifier]”

- string sm2dsa_signature_blob
■ SM2 Key Exchange Protocol (SM2KEP) Key Exchange Method Names - It is defined by family of method names “sm2kep-sha2-*” and “sm2kep-sm3-*”.
■ SM2 Key Exchange messages - The key exchange message sent in SSH protocol is not encrypted. Therefore, the packet capture enables an auditor to identify key exchange method used.
The request packet by the client to the server in the SSH handshake contains SM2 Key exchange protocol (SM2KEP), SM2 Digital Signature Algorithm (SM2DSA) amongst the SM2 methods and cryptographic hash algorithm (SM3), which are integrated in the SSH. This leads to modification of the request packet to SSH_MSG_KEYX_INIT. Moreover, the handshake also contains new messages SSH_MSG_KEX_SM2KEP_INIT by the client and SSH_MSG_KEX_SM2KEP_REPLY by the server.
BRIEF DESCRIPTION OF THE DRAWINGS
The detailed description is described with reference to the accompanying figures. In the figures the left-most digit of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to reference like features and components
Figure 1 illustrates the key exchange in the prior art.
Figure 2(a) and Figure (b) illustrates the key exchange using the SM2 method in the SSH according to an embodiment of the present disclosure.
Figure 3 illustrates a client -server handshaking architecture according to an embodiment of the present disclosure.
DEATILED DESCRIPTION
Exemplary embodiments now will be described with reference to the accompanying drawings. The disclosure may, however, be embodied in many different forms and should not be construed

as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey its scope to those skilled in the art. The terminology used in the detailed description of the particular exemplary embodiments illustrated in the accompanying drawings is not intended to be limiting. In the drawings, like numbers refer to like elements.
The specification may refer to “an”, “one” or “some” embodiment(s) in several locations. This does not necessarily imply that each such reference is to the same embodiment(s), or that the feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other embodiments.
As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless expressly stated otherwise. It will be further understood that the terms “includes”, “comprises”, “including” and/or “comprising” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. It will be understood that when an element is referred to as being “connected” or “coupled” to another element, it can be directly connected or coupled to the other element or intervening elements may be present. Furthermore, “connected” or “coupled” as used herein may include wirelessly connected or coupled. As used herein, the term “and/or” includes any and all combinations and arrangements of one or more of the associated listed items.
Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

The figures depict a simplified structure only showing some elements and functional entities, all being logical units whose implementation may differ from what is shown. The connections shown are logical connections; the actual physical connections may be different.
In addition, all logical units described and depicted in the figures include the software and/or hardware components required for the unit to function. Further, each unit may comprise within itself one or more components, which are implicitly understood. These components may be operatively coupled to each other and be configured to communicate with each other to perform the function of the said unit.
The present disclosure describes a method and a system for enhancing authentication and integrity of a cipher text by identifying a digital signature method and by identifying a key exchange protocol. The disclosure particularly relates to a handshaking, which comprises integrating elliptic curve cryptography (SM2) in the transport layer of the Secure Shell Protocol (SSH). It involves generation of a request by the client to define keys and parameters to be employed generation of a request by the client to define the signature method to be used, receiving a response by the server for the request generated by the client.
Incorporation of SM2 in SSH comprises initiating a temporary key pair and a set of parameters by the client ,verification of the temporal key pair and validation of the set of parameters by the server, generation of a temporary key pair, set of parameters and a host key by the server, computation of the shared secret between the client and the server by the sever, generation of a hash based on a certain set of parameters, signing of an exchange hash by the server and computation and verification of the shared secret and the hash by the client .
Following exchange methods are employed in the handshaking protocol :
SSH SM2 Public Key Algorithm
The “sm2dsa-sha2-*” and “sm2dsa-sm3-*” public key formats and corresponding signature formats are defined by the following family.

■ Key Format
- The “sm2dsa-sha2-*” key formats have the following encoding:
• string “sm2dsa-sha2-[identifier]”
• byte[n] ecc_key_blob
- The ecc_key_blob value has the following specific encoding:
• string [identifier]
• string Q

- The string [identifier] is the identifier of the elliptic curve domain parameters.
- string Q is the public key encoded from an elliptic curve point into an octet string as defined in Section 4.2.5 of SM2 specification; point compression may be used.
- The algorithm for ECC key generation can be found in Section 6.1 of SM2 specification. Given some elliptic curve domain parameters, an ECC key pair may be generated containing a private key (an integer d), public key (an elliptic curve point Q)
- Similarly, “sm2dsa-sm3-*” key formats have the following encoding:

• string “sm2dsa-sm3-[identifier]”
• byte[n] ecc_key_blob
■ Signature Algorithm
- Signature and verifying is done using the SM2 Digital Signature Algorithm (SM2DSA) specified in Part 2 of SM2 specification. The message hashing algorithm is from [SM3] or SHA2 family of hash functions [FIPS-180-3] and is chosen according to the curve size.
- Signature Encoding
• Signatures are encoded as follows:
■ string “sm2dsa-sha2-[identifier]”
■ string sm2dsa_signature_blob

• The string [identifier] is the identifier of the elliptic curve domain parameters
• The sm2dsa_signature_blob value has the following specific encoding:
■ mpint r

■ mpint s
• The integers r and s are the output of the SM2DSA algorithm. The width of the integer fields is determined by the curve being used.
• Similarly “sm2dsa-sm3-*” signature all have following encoding:

■ string “sm2dsa-sm3-[identifier]”
■ string sm2dsa_signature_blob
Method Names
■ Elliptic Curve Domain Parameter Identifiers
- For the elliptic curves nistp256, nistp384, and nistp521, the elliptic curve domain parameter identifiers are the strings "nistp256", "nistp384", and "nistp521“ as defined in [RFC5656].
- For the SM2 recommended 256-bit prime field elliptic curve defined in [SM2CURVE], the identifier string is “sm2p256”.
- For all other elliptic curves, including all other NIST curves and all other RECOMMENDED curves, the elliptic curve domain parameter identifier is the ASCII period-separated decimal representation of the Abstract Syntax Notation One (ASN.1) [ASN1] Object Identifier (OID) of the named curve domain parameters as defined in [RFC5656].
■ SM2 Public Key Algorithms
- SSH SM2 public key algorithm is specified by family of public key format
identifiers
• “sm2dsa-sha2-*” : Each identifier is concatenation of “sm2dsa-sha2-” and identifier defined above.
• “sm2dsa-sm3-*” : Each identifier is concatenation of “sm2dsa-sm3-” and identifier defined above.
■ SM2 Digital Signature Algorithm
- The hashing algorithm used along with SM2DSA is from SM3 or SHA2 family.
The algorithm from the SHA2 family is chosen based on the size of the named
curve specified in the public key:


In the above table, ‘ b ’ represents the size of the curve
SM2 Key Exchange Method Names:
■ SM2KEP Key Exchange Method Names
- The SM2 Key Exchange Protocol (SM2KEP) key exchange is defined by family of method names “sm2kep-sha2-*” and “sm2kep-sm3-*”.
- Each method name is the concatenation of “sm2kep-sha2-” or “sm2kep-sm3-” with the elliptic curve domain parameter identifier as defined above.
- For example, the method name for SM2KEP key exchange with ephemeral keys generated on the sect409k1 curve is “sm2kep-sha2-1.3.132.0.36".
- The algorithm from the SHA2 family is chosen based on the size of the named curve specified in the method name
■ Key Exchange Messages
- The message numbers 30-49 are key-exchange-specific and in a private namespace defined in [RFC4250] that may be redefined by any key exchange method [RFC4253] without requiring an IANA registration process.
- The following message numbers have been defined:
• #define SSH_MSG_KEX_SM2KEP_INIT 30
• # define SSH_MSG_KEX_SM2KEP_REPLY 31
SM2KEP Key Exchange
■ The SM2 Key Exchange Protocol (SM2KEP) key exchange method generates a shared secret from an ephemeral local elliptic curve private key, ephemeral remote elliptic curve public key and random point. This key exchange method provides explicit server authentication as defined in [RFC4253] using a signature on the exchange hash.
■ Algorithm negotiation chooses the public key algorithm to be used for signing and the

method name of the key exchange. The method name of the key exchange chosen determines the elliptic curve domain parameters and hash function to be used.
■ All elliptic curve public keys are necessarily validated after they are received. An example of a validation algorithm can be found in Section 6.2 of SM2 specification. If a key fails validation, the key exchange necessarily fails.
■ The elliptic curve public keys (points) and random point that are necessarily transmitted are encoded into octet strings before transmission. The transformation between elliptic curve points and octet strings is specified in section 4.2.5 of SM2 specification; point compression may be used.
■ The output of shared key generation is byte string. The SSH framework requires that the shared key be an integer. The conversion between byte string to integer is specified in section 4.2.2 of SM2 specification.
■ The output length of shared key generation is equivalent to the digest length of the hash function used during key exchange. The hash function is obtained from the method name of the key exchange.
Figure 2(a) illustrates a mechanism to integrate the SM2 algorithm within the transport layer of the SSH protocol according to an embodiment of the present disclosure. The figure illustrates the initiation of processing at the client node (201) and the processing conducted at the server end (202). The SSH versions are then checked and verified (203 and 204).A request is generated by the client to the server (205) for identification of the signature algorithm and the key exchange protocol to be employed during the handshake protocol. The client request message SSH_MSG_KEYX_INIT contains sm2kep-sha2-[identifier] or sm2kep-sm3-[identifier] and sm2dsa-sha2-[identifier] or sm2dsa-sm3-[identifier] (212). The request for the key exchange protocol mandates naming of the keys to be used during the exchange along with the elliptic curve parameters. The server responds to the request initiated by the client (206) defining the signature algorithm and the key exchange protocol. The client then generates an ephemeral or a temporary key pair at (207), containing client’s private key and a corresponding public key to be used by the server (202). The keys to be used during the handshaking are used for a one time

operation only. Alongside, the client also generates its random point. A random point is a
parameter generated by both the client and the server, which is required during computation of
the shared secret. The message by the client is encoded in the form of
SSH_MSG_KEX_SM2KEP_INIT (213). The temporal client public key and the random point
are then validated by the server (208) where the server responds with
SSH_MSG_SM2KEP_REPLY (214). The reply byte string of the server comprises server’s random point, server’s temporal public key and server’s public host key. The host key is a public key generated by the server and is used to sign on the hash while ascertaining that the key exchange has been done with the right server. This facilitates authentication of the sender and receiver and overall confidentiality of information.
The shared secret information is generated based on the public key of the client and the private key of the server or public key of the server and the private key of the client. The shared secret when extracted by both ends i.e. by the client and the server has to be the same. A hash value is computed, which is known as the exchange hash H by the concatenation of the following:
• string ZK_S, server's Z value for public host key K_S
• string I_C, payload of the client's SSH_MSG_KEXINIT
• string I_S, payload of the server's SSH_MSG_KEXINIT
• string Z_C, client's Z value for ephemeral key
• string Z_S, server's Z value for ephemeral key
• string R_C, Random point generated by Client
• string R_S, Random point generated by Server
• string V, Shared secret elliptic curve point V encoded as octet string where

• V – is the shared point generated by server as specified in Step B6, section 6.1, Part 3 of SM2 specification. xV and yV value are encoded as an octet string as defined in Section 4.2.5 of SM2 specification;
• Z_S and Z_C are the generated Z value as specified in section 5.5, Part 3 of SM2 specification;
• ZK_S is the generated Z value as specified in section 5.5, Part 2 of SM2

specification; • Z_S = HASH(V_S len in bits | V_S | a | b | xG | yG | xS | yS) where
- V_S, server's identification string (CR and LF excluded)
- xS and yS are ephemeral server public key point coordinates
- a and b are the elliptic curve parameters
- xG and yG are coordinates of base point of the elliptic curve
■ Similarly, Z_C is the Z value for client;
■ Similarly, ZK_S is calculated for the host key of the server.
The server computes the signature on the exchange hash by using private key corresponding to the server public host key K_S and replies to the client with the byte string SSH_MSG_KEX_SM2KEP_REPLY (214). The hash function to be used during the Z calculation in SM2DSA is obtained from the method name of the signature. The signature is generated as per section 6.1, Part 2 of SM2 specification.
After receiving SSH_MSG_KEX_SM2KEP_REPLY, the client validates the public keys (Q_S, K_S) and random point (R_S) obtained from server. It computes the shared secret (K) and verifies the exchange hash (H) sent by server.
The shared secret K is generated by client and server as specified in step B7 and A8, section 6.1, part 3 of SM2 specification.
- K = KDF(xV | yV | ZC | ZS, hash_size)
- The hash function to be used during the KDF operation in SM2KEP, is obtained from the method name of the key exchange
- hash_size - corresponds to the digest size of the hash function used during key exchange.
Following is the representation used in SSH for SM2KEP Key exchange with the definition of the variables below:
Client Server
Generate ephemeral key pair

SSH_MSG_KEX_SM2KEP_INIT >
Verify received key and random
point are valid.
Generate ephemeral key pair.
Compute shared secret.
Generate and sign exchange hash.
< SSH_MSG_KEX_SM2KEP_REPLY
■ The client generates ephemeral key pair and R_C. R_C is the Random point R generated by client .
■ The client sends:

- byte SSH_MSG_KEX_SM2KEP_INIT
- string R_C, Random point generated by client
- string Q_C, client's ephemeral public key octet string
■ The server responds with:
- byte SSH_MSG_KEX_SM2KEP_REPLY
string R_S, Random point string K_S, server's public host key string Q_S, server's ephemeral public key octet string string the signature on the exchange hash where
- R_S - Is the Random point R generated by server
- K_S - Is the server public host key in “sm2dsa-sha2-*” or “sm2dsa-sm3-*” public key format.
Figure 2(b) illustrates that the client request message SSH_MSG_KEYX_INIT according to present disclosure contains sm2kep-sha2-[identifier] or sm2kep-sm3-[identifier] and sm2dsa-sha2-[identifier] or sm2dsa-sm3-[identifier] (212). The message by the client is encoded in the form of SSH_MSG_KEX_SM2KEP_INIT (213). After the temporal client public key and the random point is alidated by the server, the server responds with SSH_MSG_SM2KEP_REPLY (214).

.Figure 3 illustrates a client –server handshaking architecture according to an embodiment of the present disclosure. The client (301) comprises a request unit (304) and an integration unit (303). The server (302) constitutes a response unit (305) and an integration unit (313). The request unit (304) of the client (301) generates a request to the server (302) asking for the identification of the signature algorithm and the key exchange protocol to be employed during the handshaking. The key exchange query generated requests the server (302) for the keys and the parameters to be used. The keys to be used during a particular handshaking are used for a one time operation only. The byte string is in the form of SSH_MSG_KEYX_INIT, which contains sm2kep-sha2-[identifier] or sm2kep-sm3-[identifier] and sm2dsa-sha2-[identifier] or sm2dsa-sm3-[identifier]. The response unit (305) of the server (302) replies to the request with the signature algorithm and key exchange protocol.
The integration unit 303 and 313 allows integration of elliptic curve cryptography (SM2) in the transport layer of the Secure Shell Protocol (SSH). The integration unit (303) comprises an initiator (306) and a voucher (312). The integration unit (313) comprises a verifier (307), a generator (308), an extractor (309), a hash unit (310) and an exchange unit (311). The initiator
(306) generates a temporary key pair comprising a private key and a corresponding public key of the client (301). It also generates a random point and sends the message packet to the verifier (307). The message of the initiator (306) is encoded as SSH_MSG_SM2KEP_INIT. The verifier
(307) validates the keys received from the client (301). It also validates the random point received from the client (301).
The generator (308) then produces temporal key pair comprising a private key and a corresponding public key for the server (302). Alongside, the generator (308) also produces a random point and a host key for the server (302) and sends a reply byte string to the client (301). As discussed earlier, the host key of the server (302) is a public key which, is generated at the server end alone. It is used for the purpose of signature on the hash while ascertaining that the key exchange has taken place with the right server. This facilitates authentication of the sender and receiver and overall confidentiality of information.

The extractor (309) generates a shared secret information based on the public key of the client (301) and the private key of the server (302) or public key of the server (302) and the private key of the client (301). When the shared secret information is extracted by both ends i.e by the client (301) and the server (302), the extracted information has to be the same. A hash value is computed by the Hash unit (310) which is known as the exchange hash H by the concatenation of the variables as described below:
• string ZK_S, server's Z value for public host key K_S
• string I_C, payload of the client's SSH_MSG_KEXINIT
• string I_S, payload of the server's SSH_MSG_KEXINIT
• string Z_C, client's Z value for ephemeral key
• string Z_S, server's Z value for ephemeral key
• string R_C, Random point generated by Client
• string R_S, Random point generated by Server
• string V, Shared secret elliptic curve point V encoded as octet string where

• V - is the shared point generated by server (302) as specified in Step B6, section 6.1, Part 3 of SM2 specification. xV and yV value are encoded as a octet string as defined in Section 4.2.5 of SM2 specification;
• Z_S and Z_C are the generated Z value as specified in section 5.5, Part 3 of SM2 specification
• ZK_S is the generated Z value as specified in section 5.5, Part 2 of SM2 specification
• Z_S = HASH(V_S len in bits | V_S | a | b | xG | yG | xS | yS) where

- V_S, server's identification string (CR and LF excluded)
- xS and yS are ephemeral server public key point coordinates
- a and b are the elliptic curve parameters
- xG and yG are coordinates of base point of the elliptic curve
■ Similarly Z_C is the Z value for client
■ Similarly ZK_S is calculated for the host key of the server

The Exchange unit (311) computes the signature on the exchange hash by using private key corresponding to the server public host key K_S and replies to the client (301) with the byte string SSH_MSG_KEX_SM2KEP_REPLY (214). The hash function to be used during the Z calculation in SM2DSA is obtained from the method name of the signature. The signature is generated as per section 6.1, Part 2 of SM2 specification.
After receiving SSH_MSG_KEX_SM2KEP_REPLY, the voucher (312) validates the public keys (Q_S, K_S) and random point (R_S) obtained from exchange unit (311). It computes the shared secret (K) and verifies the exchange hash (H) sent by server (302).
The shared secret K is generated by client (301) and server (302) as specified in step B7 and A8, section 6.1, part 3 of SM2 specification.
– K = KDF(xV | yV | ZC | ZS, hash_size)
– The hash function to be used during the KDF operation in SM2KEP, is obtained from the method name of the key exchange
– hash_size - corresponds to the digest size of the hash function used during key exchange. The use of SM2 in the SSH transport layer makes SSH more secure. SM2DSA enhances the authentication of the signature compared to the ECC algorithm, as not only the message is hashed but also some parameters referring to signer and system are hashed.
Both SM2 and international standard ECC algorithm are based on a discrete logarithmic problem. Compared to cryptosystems such as RSA, the Digital Signature Algorithm (DSA), and Diffie-Hellman (DH) key exchange, ECC variations on these schemes offer equivalent security with smaller key sizes. This is illustrated in the following table, based on Section 5.6.1 of NIST 800-57 [NIST-800-57], which gives approximate comparable key sizes for symmetric- and asymmetric-key cryptosystems based on the best known algorithms for attacking them. L is the field size and N is the sub-field size.



As will be appreciated by one of skill in the art, the present invention may be embodied as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, a software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product on a computer-usable storage medium having computer-usable program code embodied in the medium.
Furthermore, the present invention was described in part above with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention.
It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function/act specified

in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus like a scanner/check scanner to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowchart and schematic diagrams illustrate the architecture, functionality, and operations of some embodiments of methods, systems, and computer program products for managing security associations over a communication network. In this regard, each block may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in other implementations, the function(s) noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending on the functionality involved.
In the drawings and specification, there have been disclosed exemplary embodiments of the invention. Although specific terms are employed, they are used in a generic and descriptive sense only and not for purposes of limitation, the scope of the invention being defined by the following claims.

WE CLAIM:
1. A method for enhancing authentication and integrity of a secure
communication in a secure shell protocol (SSH), said method comprising
initiating a request for definition of keys and a set of parameters to be employed using SM2 by a client;
requesting for definition of a signature method using SM2 by the client ;
transmitting the request generated by the client to a server using SM2;
receiving a response from the server for the request for the signature method , keys and the set of parameters generated by the client; characterized in that the method comprises
integrating SM2 in the Secure Shell Protocol(SSH) using key exchange
protocol (SM2KEP) , the digital signature (SM2DSA)method and a
cryptographic hash method (SM3).
2. The method as claimed in claim 1, wherein, the definition of keys include elliptic curve key pair comprising either a public key and/or a private key
3. The method as claimed in claim 1, wherein integrating SM2 in the SSH comprises: -
initiating a temporary elliptic curve key pair and a set of parameters, a field in a key exchange message by the client;
verifying the temporal elliptic curve public key and validating the set of parameters and the field in the key exchange message by the server;
initiating the temporary elliptic curve key pair and the set of
parameters, the field in the key exchange message and a previously
generated host key by the server;
extracting secret information shared between the client and the
server, by the sever;

generating a hash key based on a certain set of parameters by the
client;
signing an exchange hash using the server host key; and
extracting and verifying the shared secret information and the hash
key by the client
4. The method as claimed in claim 3, wherein the hash key comprises at least the cryptographic hash method (SM3) or SHA2 family of hash functions.
5. The method as claimed in claim 3, wherein the field in the key exchange message comprises a random point.
6. The method as claimed in claims 1 and 3 wherein the keys initiated and verified by the client and the server are temporary keys generated for a one time operation.
7. The method as claimed in claim 3, wherein the host key is generated by the server.
8. The method as claimed in claim 3wherein the host key generated comprises a public key and a private key.
9. The method as claimed in claim 3, wherein the host key is used by the server in signing the hash to be sent to the client.
10. The method as claimed in claim 3, wherein initiating a temporary key pair by the client includes a public key and a private key.
11. The method as claimed in claim 3, wherein verifying comprises validating the temporal public key of client and the random point by the server.

12. The method as claimed in claim 3, wherein generating a temporary key pair by the server comprising a public key and a private key.
13. The method as claimed in claims 3 and 8, wherein the host key generated by the server ascertains that the key exchange has been done with the right server.
14. The method as claimed in claim 3, wherein the shared secret information is extracted using the temporal public key of the client and the temporal private key of the server or the temporal private key of the client and the temporal public key of the server.
15. The method as claimed in claims 3 and 14, where the shared secret information extracted by both the client and the server is the same.
16. The method as claimed in claim 3, wherein the hash is generated using the parameters , taken in any order, comprising a unique information about the owner of public key (ZK_S, Z_S and Z_C) for both the client and the server, SSH_MSG_KEXINIT payload of the client and the server (I_C and I_S), the random point generated by the client and the server (R_C and R_S) and a shared secret point generated by the server (V).
17. The method as claimed in claims 3and 16, wherein the Z value of server temporary key(Z_S )/ client temporary key (Z_C)/server host key(Z_KS) is a hash function of V,x and y which are temporal public key point coordinates of server/client /server host, a and b which are the elliptic curve parameters, xG and yG which are coordinates of base point of the elliptic curve, denoted by Z_S=HASH(V_S len in bits | V_S | a | b | xG | yG | xS | yS), Z_C=HASH(V_C len in bits | V_C | a | b | xG | yG | xC | yC), and Z_KS=HASH(V_KS len in bits | V_KS | a | b | xG | yG | xKS | yKS).

18. The method as claimed in claim 17, wherein Z_S is the Z value for server temporary key, Z_C is the Z value for the client temporary key and Z_KS is the Z value for the server host key.
19. The method as claimed in claim 3 , wherein the exchange hash is signed using the private key corresponding to the public host key of the server.
20. The method as claimed in claim 3, wherein extracting and verifying
the shared secret information and the hash by the client involves verification
of the public host key obtained from the server.
21. The method as claimed in claim 20 wherein the client extracts the shared secret at its end after verification of the temporal public key and the random point obtained from the server.
22. The method as claimed in claim 3, wherein the length of the shared secret information generated during the key exchange is based on the hash used in the SM2KEP.
23. The method as claimed in claim 19, wherein the exchange hash generated by the server is verified by the client.
24. A apparatus for enhancing authentication and integrity of a secure communication in a secure shell protocol (SSH) by identifying a digital signature method and a key exchange protocol, said apparatus comprising
a request unit configured to generate a request by the client to define keys , a signature method and a set of parameters to be employed using SM2;
a response unit configured to receive a reply for the signature method , keys and the set of parameters from the server for the request generated by the client using SM2; characterized in that

an integration unit (303 and 313) is configured to incorporate SM2 in the transport layer of the Secure Shell Protocol(SSH)using key exchange protocol (SM2KEP) , a digital signature algorithm (SM2DSA) and a cryptographic hash method (SM3)
25. The apparatus as claimed in claim 24, wherein, the definition of keys include elliptic curve key pair comprising either a public key and/or a private key
26. The apparatusapparatus as claimed in claim 24, wherein the integration unit (303) comprises
an initiator configured to generate a temporary key pair and a set of parameters and a field in a key exchange message by the client ; and
a voucher inside the client configured to extract and verify the shared secret and the hash key.
27. The apparatusapparatus as claimed in claim 24, wherein the
integration unit (313) comprises
a verifier configured to verify and validate the temporal key pair and the set of parameters and the field in the key exchange message;
a generator configured to produce a temporary key pair ,a set of parameters ,a field in the key exchange and a previously generated host key by the server;
an extractor configured to compute shared secret between the client and the server ;
a hash unit configured to generate a hash key based on a certain set of parameters; and
an exchange unit configured to signing an exchange hash key by the server using the server host key
28. The apparatus as claimed in claims 26and 27, wherein the hash key
comprises at least SM3 or SHA2 family of hash functions

29. The apparatus as claimed in s 26 and 27, wherein the field in the key exchange includes a random point.
30. The apparatus as claimed in claims 26 and 27 wherein the keys initiated and verified by the client and the server are temporary keys generated for a one time operation only.
31. The apparatus as claimed in claim 27, wherein the host key is initiated by the server.
32. The apparatus as claimed in claim 27 wherein the host key includes both public and private key.
33. The apparatus as claimed in claim 27, wherein the host key is used by the exchange unit in the server to sign on the hash.
34. The apparatus as claimed in claim 26 wherein the initiator generates a public key and a private key
35. The apparatus as claimed in claim 27, wherein the verifier verifies the keys and validates the random point
36. The apparatus as claimed in claim 27, wherein the generator produces a public key and a private key
37. The apparatus as claimed in claims 27 and 31, wherein the host key ascertains that the key exchange has been done with the right server
38. The apparatus as claimed in claim 27, wherein the shared secret is extracted using the public key of the client and the private key of the server or the private key of the client and the public key of the server.

39. The apparatus as claimed in claims 27 and 38, where the shared secret extracted by both the client and the server is the same.
40. The apparatus as claimed in claim 27, wherein the hash unit generates hash key using the parameters, taken in any order , which includes unique information about the owner of public key (ZK_S, Z_S and Z_C) for both the client and the server, SSH_MSG_KEXINIT payload of the client and the server (I_C and I_S), the random point generated by the client and the server (R_C and R_S) and a shared secret point generated by the server (V)
41. The apparatus as claimed in claims 27 and 40, wherein the Z value of server temporary key(Z_S )/ client temporary key (Z_C)/server host key(Z_KS) is a hash function of V which is identification string of server/ /client /server host ,x and y which are temporal public key point coordinates of server/client /server host, a and b which are the elliptic curve parameters, xG and yG which are coordinates of base point of the elliptic curve, denoted by Z_S=HASH(V_S len in bits | V_S | a | b | xG | yG | xS | yS), Z_C=HASH(V_C len in bits | V_C | a | b | xG | yG | xC | yC), and Z_KS=HASH(V_KS len in bits | V_KS | a | b | xG | yG | xKS | yKS).
42. The apparatus as claimed in claim 41, wherein Z_S is the Z value for server temporary key, Z_C is the Z value for the client temporary key and Z_KS is the Z value for the server host key
43. The apparatus as claimed in claim 27 , wherein the exchange hash is signed inside the exchange unit using the private key corresponding to the host key of the server
44. The apparatus as claimed in claim 26, wherein the voucher of the
client verifies the public host key obtained from the server and then extracts
the shared secret.

45. The apparatus as claimed in claim 44, wherein the client computes the shared secret at its end after validation of the public key and the random point obtained from the server.
46. The apparatus as claimed in claim 27, wherein the length of the shared secret generated during the key exchange is based on the hash used in the SM2KEP
47. The apparatus as claimed in claim 43, wherein the exchange hash generated by the server is verified by the client.
48. A computer readable medium for enhancing authentication and integrity of a secure communication in a secure shell protocol (SSH), comprising
initiating a request for definition of keys and a set of parameters to be employed using SM2 by a client;
requesting for definition of a signature method using SM2 by the client ;
transmitting the request generated by the client to a server using SM2;
receiving a response from the server for the request for the signature method , keys and the set of parameters generated by the client; characterized in that the method comprises
integrating SM2 in the Secure Shell Protocol(SSH) using key exchange
protocol (SM2KEP) , the digital signature (SM2DSA)method and a
cryptographic hash method (SM3), and
wherein, the definition of keys include elliptic curve key pair comprising either a public key and/or a private key.