Elliptic Curve Cryptographic Security in

Transmission Control Protocol

Suhas J Manangi, Parul Chaurasia, Mahendra Pratap Singh
suhasjm@gmail.com, stylishparul@gmail.com, mps_82@aol.in
Department of Computer Engineering, NITK-Surathkal, India

Abstract: Security is one of the prime concerns in the

Internet world today. Considering 5 Layer Internet
Model, most of the security functions are at
Application layer and few at IP layer, there is very
limited work in regard with security at Transport
Layer. This paper gives a detailed description of need
of security at TCP and also proposed basic design of
Elliptic Curve Cryptographic Security to TCP.
Key Words: Secure Socket Layer, Transport Layer
Security, Key Establishment, Public Key Encryption,
ECC, TCP, Secure-TCP, IP-Sec.
I.

3.

Scope of this paper is limited to areas involving the

security of application data during TCP
communication but not in all aspects of security in
internet. With this limitation this paper considers 3
objectives to be achieved.
TCP providing secure
Application Layer.

communication

for

Using Elliptic Curve Cryptography in TCP

security.
Lesser overhead in key establishment process
and efficient inter-operability with current TCP.
II.

1.
2.

INTRODUCTION

Transmission Control Protocol [1] of Transport

Layer provides data flow control, congestion
mechanism, error control, sequencing, reliability etc.
But at todays world security is major concern which
cant be neglected. TCP/IP protocol suite was
conceived in an environment that was quite different
from the present hostile environment. Since the
security aspects were not well thought of during the
design of TCP protocol, security functions are
integrated with application in todays scenario. But in
this process traditional applications have become
outdated due to lack of security, and newer
applications are developed with great care regarding
security issues if to be used over internet and on new
cryptographic methods and security threatened
applications have to be rebuilt or revised. The
acceleration of integrating security features to
applications is much slower than needed. Our work in
this paper is mainly intending to shift the security
function from application layer to transport layer thus
applications could be free of security features to
some extent.

1.

2.

3.
4.

5.

6.

NEED FOR SECURITY AT TCP [2]

Lot of resources is wasted in building security in

new Applications.
The existing Application without any security
either will be taken over by other applications or
consumes much time and resources in building
security features (Increased use of SSH over
Telnet is due to absence of security features in
Telnet).
Requirement of process to process security and
even connection level security.
TCP cannot guard a segment against the message
modification attacks. TCPs checksum field is
used in order to identify a modification of a
segment. However, since this field is not
protected against the message modification
attacks, it is possible to modify any TCP
segment. Moreover, there is no way for peer
entities to trace out the message modification
attacks.
TCP cannot keep segment data secure against the
message eavesdropping attacks. TCP transports
stream data used in the application layer. Since
TCP does not provide any data encryption
functions, anyone can gain any valuable
information.
TCP cannot protect connections against the
unauthorized access attacks. TCP certifies a peer
entity by a source IP address and a port number.
However, it is possible to modify the source
address and port number.

All these could be easily solved by including

security features at Transport Layer providing
services to Application layer. That is why security
features at TCP levels become essential. Since TCP
could provide process to process security and even
transaction/link level security, but the hindering
factor would be TCP speed which needs to be
optimized. If this is achievable then Applications can

be built without worrying about which cryptographic

system provides best security in which time.
III.

LITERATURE REVIEW

3.

4.

A. Secure-TCP [3]:
However above problems were thoroughly
addressed by Toshiyuki Tsutsumi, Suguru
Yamaguchi in their paper Secure-TCP [12] but they
used Symmetric Key Block Cipher DES which is
outdated and inefficient. The paper proposed a
method in which the reserved flag bits in TCP header
are used and additional options which made the interoperability between Secure-TCP and current TCP
isnt well established and difficult and also overhead
of key negotiation and establishment is high in this
model.
B. IP-Sec [4]:

5.

IV.

2.

3.

4.

5.

Encryption of small packets generates a large

overhead. This diminishes network performance.
IPSec is complex. It has great many features and
options. Choosing and setting an option is a bit
difficult. Complexity also increases the
probability of weakness or loop holes being
discovered.
Firewalls are preconfigured rules and IPSec
encrypts these rules in the packet which defeats
the purpose of a firewall. A solution for this
could be firewall along with an IPSec gateway.
IPSec can't provide the same end-end security as
it does not work between users or applications
but between machines
IPSec must be combined with security measures
like well configured firewalls, intrusion detection
systems, and many more. Few more issues like
scalability, flexibility and compatibility with
NAT are also not well addressed [5].

C. Transport Layer Security (TLS) [6]:

TLS originated from SSL, which provides end to
end security. It acts on top of TCP and below
application. Few disadvantages observed are:
1. It uses 1024 and 2048 Bits RSA algorithms
inside which add a lot of overhead.
2. It lacks potential scalability, particularly for
micro-transactions where session setup is
important.

ECC OVER OTHER CRYPTOGRAPHIC

ALGORITHMS

ECC is chosen as the cryptographic algorithm

here because of the following purposes [7] [8]:
1.

2.

IP-Sec is a protocol designed for IP level (Network

Layer) which basically authenticates and encrypts IP
Packets. Along with its use there are few drawbacks
that can be identified:
1.

Handling a large number of connections on a

TLS within a short period of time is
another problem and it requires special hardware.
TLS is not economic when it comes for microtransactions, because whole set up has to
take place just for a small amount of content.
Another problem is that protection has to be
applied at the same time of the content
delivery.

3.

ECC offers considerably greater security for a

given key size - something we'll explain at
greater length later in this proposal.
The smaller key size also makes much more
compact implementations for a given level of
security possible, which means faster
cryptographic operations, running on smaller
chips or more compact software. This means less
heat production and less power consumption - all
of which is of particular advantage in constrained
devices, but of some advantage anywhere.
There are extremely efficient, compact hardware
implementations
available
for
ECC
exponentiation operations, offering potential
reductions in implementation footprint even
beyond those due to the smaller key length
alone.
V.

DESIGN OF THE ECC IN TCP

ECC over Prime Field is chosen because of its

efficiency and security compared to ECC over Binary
Field.
A. Design of ECC over Prime Field [12] [13] [14]:
Elliptic Curve considered is of the form
y2 = x3 + ax + b where 4a3 + 27b2 0.
Over Prime Field (Fp) refined Elliptic Curve will be
y2 (mod p) = x3 + ax + b (mod p) where 4a3 + 27b2
(mod p) 0.
Parameters a, b, and p are chosen randomly
generally p is a very large prime number and a, b < p.
Domain parameters are shown in Figure 01.

make it multiple of 4 Bytes. First bit among

Reserved Bits in TCP is set to notify that ECC
enabled TCP is used for connection establishment.
And since types 29 to 252 are not defined in the TCP
option headers we can make use of them for key
establishment process.
Opt. No.
30
31

Size
1
2

Option Data
ECC Flags
Bits size to be used in ECC

Figure 1: Domain Parameters of Fp.

Table 1: TCP option header format

In the system, client will have the workload of

generating random numbers a, b, and p according to
the constraints explained above. Thus server is less
burdened by this extra security feature at TCP layer.

ECC flag bits will be set depending on which of the

elements of the Domain Parameters and Public Keys
are present in the data section.
p

B. Key Exchange:
For key exchange discrete logarithmic problem
based EC-Diffie Hellman Key Exchange [9][10]. Client
computes a, b and p and thus decides the Elliptic
Curve to be used for secure TCP communication.

cQ

sQ

Table 2: ECC Flags

Data is sent as part of TCP data along with the SYN

segments while establishing connection. Data is in
the same order as ECC flag bits, and size of each
domain parameter is fixed by the Option 31 as shown
above.
D. Encryption/Decryption [11] [12]:

Figure 2: Elliptic Curve Diffie Hellman Key Exchange

There are 2 options where ECC module could be

placed, either only data part of TCP could be
encrypted using ECC or we can take one step ahead
and encrypt everything except ports in TCP thus
keeping all the connection information also secure
along with data as shown in Figure 4 and Figure 5. At
this level a symmetric Key algorithm is used to
enhance the speed since symmetric algorithms are
much faster than asymmetric key algorithms. In this
paper AES-128 (128 bits Advanced Encryption
Standard) algorithm is used. Since ECC key size
established is not fixed a hash function is used to
generate a 128 bit AES symmetric key from the ECC
key computed through the key exchange phase.

C. TCP header format:

Present Option header format in TCP is as
follows and current occupied numbers are shown in
Figure 1. Kind and Length are of 1 Byte each, and
depending on the length information could be
possible following which is sequence of 0s to pad to

Figure 3: ECC Key to AES Key

has to be opened even if it is duplicate packet thus

resulting in low throughput. Thus encrypting only
TCP data is more efficient.
E. Algorithms in ECC [12]
Algorithm for Generating Domain Parameters of
ECC over Fp [16]:

Figure 4: Secured TCP communication

Select a prime P such that GIF(Log2P) = 521

(for 256 Bits security, the prime number
generated should be in the range of 256 bits
length)
Select a,b Fp i.e.., [1,P-1] satisfying the curve
E : y2 x3 + ax + b (mod P)
Select a base point G on the curve E(Fp)
Select a prime number n with order of G and an
integer h which is cofactor h = #E(Fp)/n
with following constraints
4a3 + 27b2 0 (mod P)
#E(Fp) P
PB 1 (mod P) for all 1 B 20
h4
Domain Parameters (P, a, b, G, n, h)

Algorithm for Validating EC Domain Parameters [16]:

Figure 5: Only TCP data is Secure

Check if P is a prime number such that GIF(Log

P) = 521
Check if a, b belongs to [1,P-i] and G belong to
E(Fp)
Check that 4a3 + 27b2 0 (mod P)
Check if n is a prime
Check that nG = O
4a3 + 27b2 0 (mod P) and nh P

Algorithm for EC Key Pair Generation [16]:

Randomly select an integer d which belongs to

[1,n-1]
Calculate Q = dG
Q is the public key, and d is the private key

Algorithm for Validation of Key Pair [16]:

Figure 6: Except Port Numbers all other TCP information is Secure

On analysis, it would show that if complete TCP

packet is encrypted except port numbers then packet

Check that Q O
G belongs to the E(Fp) curve
nQ = O

VI.

SECURITY ANALYSIS ON EC
CURVES[12][13][14]

There are so many kinds of EC Curves which

make ECC vulnerable like Super Singular Curves,
Anomalous Curves, and Koblitz Curves[16][17]. These
curves are exploited in the know attacks like Baby
Step and Giant Step method, MOV attack [20],
Pollardp-attack[21] etc. Because of these reasons
curves have to chosen carefully. The curve must
therefore satisfy following conditions:

VII.

Figure 7: Interoperability Scenario 1

There exists a large prime P dividing #E(Fp) so

that the problem is not susceptible to Pollard-pattack
#E(Fp) q (ie. The curve is not anomalous).
This prevents the problem from being
susceptible to the Semaev Smart Araki attack
The order of P does not divide qk 1 for all k
such that 1 k C, where C is a sufficiently
large constant so that it is difficult to solve the
discrete logarithm problem in Fp. This is
necessary for MOV not to generate a solution
quickly.

Since in a TCP connection, its always client who

starts the initiation (logically we can consider so),
server receives the modified TCP SYN Segment with
ECC parameters. If server is running ECC enabled
TCP then the proposed action as explained in this
paper will be carried on, and if normal TCP is used
then the server will respond in normal way of sending
its SYN and ACK without any domain parameters,
and when client side receives SYN+ACK packet
without ECC domain parameters doesnt encrypt the
packets there on. Thus ECC enabled TCP could be
easily deployed with full interoperability with present
TCP.
VIII.

ADVANTAGES AND DISADVANTAGES

Advantages that are possible in integrating ECC

security in TCP are:
1.

2.

Figure 8: Interoperability Scenario 02

INTEROPERABILITY WITH PRESENT TCP

TCP provides security features to Application

layer. ECC enabled TCP provided process to
process security, thus applications can be built
exploiting these services which would need no
extra security functionalities.
Traditional applications could be run over this
ECC enabled TCP.

3.

4.
5.

Lesser development time for newer applications

since security aspects are already taken care by
proposed TCP.
Use of ECC in the system provides better
security than any algorithm existing.
Full interoperability with present TCP allows
adoption of ECC enabled TCP in the existing
network.

Along with advantages few disadvantages can also be

observed in the proposed system:
1.

2.

Overhead caused would affect the throughput of

TCP. So in high speed networks ECC enabled
TCP would become a bottleneck.
In the proposed system, cryptographic
algorithms emerging in future are not taken care
of which might be better than ECC.
IX.

CONCLUSIONS

Elliptic Curve Cryptography cab be merged into

TCP bringing security features into TCP. There is lot
of scope to make improvements in the throughput of
ECC enabled TCP by buffering techniques, and
carefully placing the decryption module during

implementation. But as seen from the point of

security services provided to Application layer,
proposed integration with further enhancement of
performance would give an overall better
performance and rapid adoption of applications in
exploiting the security services provided by TCP.
X.
1.

2.

3.

FUTURE WORKS

Key establishment can be done periodic for the

better security using option header formats in
TCP. This could be done with additional option
headers.
Proposed system only addresses confidentiality
of the TCP data, but future works can include
extending this to include data integrity using
hash functions and authentication mechanisms.
ECC enabled TCP works fine with IPv4 but it
needs changes and improvements for IPv6
system to take care of features like Multicast
packets.
REFERENCES:
[1]. RFC:
793
TRANSMISSION
CONTROL
PROTOCOL
[2]. Security assessment of the Transmission Control
Protocol (TCP) Technical notes archive ID:
00003 Ref: TN0309 Date: February 2009
[3]. Secure TCP - providing security functions in
TCP layer INET95 Paper no:144
[4]. RFC : IP-Sec 2401, 2412
[5]. RFC 3715: IP-Sec compatibility with NAT
[6]. RFC 2246: The TLS Protocol Version 1.0 and
RFC 4346: The TLS Protocol Version 1.1
[7]. Washingtion, Lawrence C. Elliptic Curves:
Number Theory and Cryptography. Boca Raton,
FL: CRC Press, 2003.
[8]. Darrel Hankerson, Alfred J. Menezes, and Scott A.
Vanstone. Guide to Elliptic Curve Cryptography.
Springer, Berlin, 2003.
[9]. Whitfield Diffie and Martin E. Hellman. New
directions in cryptography. IEEE Transactions on
Information Theory, IT-22(6):644654, Nov 1976.
[10].
Daniel J. Bernstein. Curve25519: new DiffieHellman speed records. In Public Key
Cryptography PKC 2006, volume 3958 of
Lecture Notes in Computer Science, pages 207
228. Springer, 2005.
[11].
Galbraith,
Steven.
Elliptic
Curve
Cryptography According to Steven Galbraith.
[12].
Certicom,
Standards
for
Efficient
Cryptography,
SEC
1:
Elliptic
Curve
Cryptography, Version 1.0, September 2000
[13].
N.
Koblitz,
CM-curves
with
good
cryptographic
properties,
Advances
in

Cryptology CRYPTO 91, Lecture Notes in

Computer Science, volume 576, Springer-Verlag,
pages 279-287, 1992
[14].
A. Menezes, T. Okamoto and S. Vanstone,
Reducing elliptic curve logarithms to logarithms
in a finite field, IEEE Transactions on
Information Theory, volume 39,pages 1639-1646,
1993.
[15]. J. Pollard, Monte Carlo methods for index
computation
mod
p,
Mathematics
of
Computation, volume 32, pages 918-924, 1978.
[16].
Koblitz, Neal. A Course in Number Theory and
Cryptography. New York, NY: Springer Verlag,
1994.
[17].
N. Koblitz, Elliptic curve cryptosystems,
Mathematics of Computation, Volume 48, pages
203-209, 1987.