Extrait
Table of Contents
Abstract
List of Figures
List of Table
Nomenclature
CHAPTER 1
1. Introduction:
1.1 Applications and techniques which uses embedded security:
1.2 Criteria considered choosing embedded security:
1.3 Criteria considered choosing embedded security:
1.4 Challenges faced in Embedded Security Design:
1.5 Solution to Challenges faced in Embedded Security Design:
CHAPTER 2
2. Introduction:
2.1 Functional Requirements and task identification:
2.2 Flow graph for Telemedicine Client-Server System:
2.3 Flow Chart for Telemedicine Client-Server System:
2.4 Algorithm to Telemedicine Client-Server System:
2.5 Implementation TCP socket between client and server:
2.5.1 Implementation at server side:
2.5.2 Implementation of Client side:
2.6 Implementation UDP socket between client and server:
2.6.1 Implementation at server side:
2.6.2 Implementation at Client side:
2.7 Authentication:
2.7.1 Algorithm at Server side:
2.7.2 Algorithm at Client side:
2.8 Discussion:
CHAPTER 3
3. Introduction:
3.1 AES algorithm
3.2 AES encryption and decryption:
3.2.1 Implementation of AES algorithm at server side in C code is show below:
3.2.2 Implementation of AES algorithm at client side in C code is show below:
3.2.3 Algorithm of cipher(), InvCipher(), KeyExpansion and XOR:
3.2.4 Algorithm Parameters, Symbols, and Functions:
3.3 Performance Evaluation of Telemedicine System:
3.3.1 Performance Evaluation of TCP:
3.3.2 Performance Evaluation of UDP:
3.4 Test Cases for TCP & UDP:
3.4.1 Test Cases for Server (Tcp/Udp):
3.4.2 Test Cases for Client (Tcp / Udp):
3.5 Results:
3.5.1 TCP output:
3.5.2 UDP output:
3.6 Discussion:
CHAPTER 4
4 Introduction:
4.1 Profiling and tracing Tools:
4.2 Profiling the performance of TCP server and client program of telemedicine system using Rijndaelalgorithm:
4.3 Analyzing and identifying the code where parallelism is required using the profile data:
4.4 Designing the identified section of code for parallelization using multithreading concepts:
CHAPTER 5
5.1 Pthread:
5.2 Compiling and running the code using Pthread library on the Intel duel core system
5.3 Profiling the performance of modified TCP server and client program of telemedicine system using pthread library
5.4 OpenMP
5.5 Compiling and running the code using Pthread library on the Intel duel core system
5.6 profiling the performance of modified TCP server and client program of telemedicine system using Open MP library
5.7 Execution Time and Speedup
5.7.1 Comparing the performance of TCP client-server program of telemedicine system using Rijndael algorithm for video file in single core, dual core using Pthread and dual core using OpenMP:.
5.8 Comparing the performance of TCP client-server program of telemedicine system using Rijndael algorithm for video file in single core, dual core using Pthread and dual core using OpenMP:
CHAPTER 6
6.1 Comments on Learning Outcome:
6.2 Summary/Conclusion
REFERENCES
List of Figures
Figure 2.1 Shows the flow graph of Telemedicine Client-Server system
Figure 2.2 Flow Chart for Telemedicine Client-Server System
Figure 2.3 Snap shot of output screen shot of TCP Server
Figure 2.4 Snap shot of output screen shot of TCP Client
Figure 2.5 Snap shot of output screen shot of UDP Server
Figure 2.6 Snap shot of output screen shot of UDP Client
Figure 3.1 Simple model for cryptographic algorithm[5]
Figure 3.2 Basic structure of the AES algorithm: encryption (left), decryption (right)5
Figure 3.3 Secure data transmission using AES encryption and decryption
Figure 3.4 Snap shot of performance of TCP
Figure 3.5 Snap shot of performance of UDP
Figure 3.6 Snap shot of output screen shot of TCP Server
Figure 3.7 Snap shot of output screen shot of TCP Client
Figure 3.8 Snap shot of output screen shot of UDP Server
Figure 3.7 Snap shot of output screen shot of UDP Client
Figure 4.1 Snap shot of timer function
Figure 4.2 Snap shot of flat profile for TCP server program on single core
Figure 4.3 Snap shot of flat profile for TCP client program on single core
Figure 4.4 Snap shot of call graph for TCP client-Server program on single core
Figure 4.5 Snap shot of reading the video file in the server
Figure 4.6 Snap shot of Rijndaelencryption of cideo sequence in server
Figure 4.7 Snap shot of sending nd receiving encrypted video stream from server to client
Figure 4.8 Snap shot of Rijndaeldecryption of video sequence in client
Figure 4.9 The part of the code is identified in the TCP client-server program where parallelization is
required
Figure 4.10 Parallelization of part of the code in the TCP client-server program of telemedicine system using multithreading concept
Figure 4.11 Two TCP client-Server connection is established
Figure 4.12 Transmission of video file size from server to client using socket()
Figure 4.13 Original file is divided into parts and Rijndaelencryption is applied
Figure 4.14 Transmission of two part encrypted data using two TCP client- server connections
Figure 4.15 decryption of encrypted video frame using Rijndaelalogorithm
Figure 5.1 reading video stream from server and dividing video stream into two parts
Figure 5.2 pthread is created for encrypting the video stream in the server
Figure 5.3 encryption operation is performed in thread_main1 and thread_main2
Figure 5.4 pthread is created (in both server and client) for sending and receiving encrypted video stream from server to client
Figure 5.5 sending encrypted video stream from server to client
Figure 5.6 receiving encrypted video stream in client from server
Figure 5.7 pthread is created for decrypting the video stream in the client
Figure 5.8 decryption operation is performed in thread_main1 and thread_main2
Figure 5.9 snapshot of flat profile for TCP server program on dual core using Pthread
Figure 5.10 snapshot of flat profile for TCP client program on dual core using Pthread
Figure 5.11 snap shot of call graph for TCP server program on dual core using Pthread
Figure 5.12 snap shot of call graph for TCP client program on dual core using Pthread
Figure 5.13 snap shot of section parallelization for encrypting the video stream in the Server
Figure 5.14 snap shot of section parallelization for sending and receiving encrypted video stream from server to client
Figure 5.15 snap shot of section parallelization for decrypting the video stream in the client
Figure 5.16 snapshot of flat profile for TCP server program on dual core using OpenMP .
Figure 5.17 snapshot of flat profile for TCP client program on dual core using OpenMP
Figure 5.18 snap shot of call graph for TCP server program on dual core using OpenMP
Figure 5.19 snap shot of call graph for TCP client program on dual core using OpenMP
Figure 5.20 snapshot of server execution of 7.64 MB video file .
Figure 5.21 snapshot of client execution of 7.64MB video file
Figure 5.22 snapshot of server execution of 36.8 MB video file
Figure 5.23 snapshot of client execution of 36.8 MB video file
Figure 5.24 snapshot of server execution of 96.4 MB video file
Figure 5.25 snapshot of client execution of 96.4 MB video file
Figure 5.26 snapshot of server execution of 191 MB video file
Figure 5.27 snapshot of client execution of 191 MB video file
Figure 5.28 column graph results of TCP server program is compared with normal execution in single core with pthread program
Figure 5.29 column graph results of TCP server program is compared with normal execution in single core with OpenMP program
Figure 5.30 column graph results of TCP client program is compared with normal execution in single core with Pthread program
Figure 5.31 column graph results of TCP client program is compared with normal execution in single core with OpenMP program
Figure 5.32 snap shot of comparison of TCP server program is compared with normal execution in single core with pthread and OpenMP program
Figure 5.33 snap shot of comparison of TCP server program is compared with normal execution in single core with pthread and OpenMP program
List of Table
Table 2. 1 Requirement specification of telemedicine system
Table 3.1 Test case for car using CANoe
Table 3.2 Test case for Server (TCP/UDP)
Table 3.3 Test case for Client (TCP/UDP)
Table 5.1 Different test case execution results of TCP server program is compared with normal execution in single core with pthread program
Table 5.2 Different test case execution results of TCP server program is compared with normal execution in single core with OpenMP program
Table 5.3 Different test case execution results of TCP client program is compared with normal execution in single core with Pthread program
Table 5.4 Different test case execution results of TCP client program is compared with normal execution in single core with OpenMP program
Acronyms
Abbildung in dieser Leseprobe nicht enthalten
Abstract
Multimedia applications have an increasing importance in many areas. There is a growing need to store and transmit high quality video for applications where common coding schemes do not yield enough quality. An example of this is Telemedicine system is best example of Applied Medical Informatics. Several physiologic data, Digital images and video can be transmitted more rapidly and easily than conventional images and videos. In telemedicine expert physicians in tertiary care centres can view a digital image, videos and advice local physicians on the best plan of care without having to move the patient many miles away.
Telemedicine will be implemented using the TCP client-server model. The clientserver model was originally developed to allow more users to share access to database applications. The data must be secure, when the data is transmitted from server to client, security must ensure that data will not be damaged by attackers and protects against danger, loss, and criminals. Even if someone tries to hack the data content of file should not be revealed to the attacker. So it is necessary to encrypt the data before transmitting the file using encryption methods. The encryption method used in server and client model is XOR or AES (advanced encryption standard) or Rijndael algorithm which is used to encrypt and decrypt the x-ray images of patients, drug prescriptions.
The Rijndael algorithm allows encrypt video at high quality while achieving great encryption. This property makes the Rijndael algorithm a good option for building a video encryption able to obtain better performance than other more general purpose algorithms such as XOR or AES algorithm. One of the main problems when working with the video sequence is the huge datasets that have to be dealt with. Therefore, memory accesses slowdown the encryption execution. Performance is one of the main concerns of modern systems; therefore Profiling and tracing tools is used to determine which parts of a program to optimize for speed or memory usage. A general rule of thumb is that 90% of a program's time is spent in just 10% of the code. Profiling enables you to determine which 10% of the code. The parallelization of code using multithreading concept is required to reduce execution time on the processer and speed up the application. The method of measuring performance is to arrive at the speed of execution, later, measure the execution on a single core and multi-core processor.
CHAPTER 1
1. Introduction:
Many modern electronic systems including personal computers, PDAs, cell phones, network routers, smart cards, and networked sensors to name a few need to access, store, manipulate, or communicate sensitive information, making security a serious concern in their design, against damage and data theft due to malfeasance.
This chapter gives an essay of the techniques and applications where the security finds its need in embedded systems and criteria, merits and demerits to be considered in choosing Security mechanisms, Challenges faced and solution for the challenges faced for developing a secure embedded network.
1.1 Applications and techniques which uses embedded security:
A digital signature is not a digitized hand-written signature, but a special kind of checksum. Secret information ensures that a digital signature cannot be forged, while public information enables the verification of the signature. Using digital signatures for data has numerous advantages. Digitally signed data cannot be tampered and the signer cannot repudiate that he has signed the data. Therefore, even security-critical processes can be realized in a digital way, when digital signatures are used1.
The PDA/Cell phone is quite different from a Workstation/Server in another way. They are. ‘Single user.’ systems- not one user at a time, but one user, this makes things both easier and harder. Things get easier because many of the threats and countermeasures for desktop/server systems deal with multiple users, and different security levels, on the same system, perhaps concurrently. Tremendous constraints are placed on the operating system to prevent information from going from a. ‘high level.’ security to a. ‘low level.’ security, while still allowing information to move the other way2.
Many commercial drivers, even ones used in hundreds of thousands of PDA and laptop applications may not be stable enough for a secure system. Laptops and desktops are frequently shut down allowing the drivers to purge their reserved memory. Commercial PCMCIA or CF cards are plugged in and out often, flushing the buffers and resetting the driver. Embedded systems are expected to run 24x7. Even PDAs, when shut off are not really off, but in a sleep mode where the software is in place but quiescent. Drivers need to be stress tested over long time intervals (days and weeks) to verify no leaks. Finally, there are some high security plug-in cards and USB security fobs with drivers which although well audited and tested on laptops2.
1.2 Criteria considered choosing embedded security:
Criteria’s considered while designing and choosing embedded security devices are, confidentiality, integrity, availability, authentication, and Message Authentication Codes (MACs). (1) Confidentiality: secrecy of communication between parties. Exposure of communications in wireless networks makes eavesdropping a constant threat. (2) Integrity: assurance that data has not been modified by an unauthorized party. This applies to messages in transit, records stored in databases, and even data possessed by attacked. (3) Authenticity: assurance that a message originated from a known other party. Among others, command and control systems require high confidence that actions with large or dangerous effects have been issued by appropriate means. (4) Message Authentication Codes (MACs) are often appended to protocol messages to provide this property. (5) Authorization: determination of privileges from a party's identity. (6) Availability: a service or system performs its function in a timely manner for legitimate users. Denial of service attacks may crash a system completely, or may only slow it down enough to cause significantly irrupted service3.
1.3 Criteria considered choosing embedded security:
Merits: Embedded security enhances with confidentiality, integrity, availability, authentication, and increased data security, system protection, against damage and data theft due to malicious attack. Demerits: Including security at embedded level increases cost of product. Including security algorithm requires more amount of flash memory3.
1.4 Challenges faced in Embedded Security Design:
Challenges faced in embedded security design in are ECU software integrity protection, ECU software IP protection, secure information logging, Prevent use of non-original parts, and secure communication, Digital Rights Management, and Multi-ECU consolidation. (1) ECU SOFTWARE INTEGRITY PROTECTION: ECU software resides on a permanent external storage device (e.g. external flash, external RAM), which is relatively easy to access by simple off-the-shelf tools. An attacker can replace parts of the ECU software image or the entire image on external storage, causing the ECU to execute software which was not originally provided or approved by the manufacturer. Such software modifications can cause a wide range of undesired system behavior4. (2) ECU SOFTWARE IP PROTECTION: The software code image that the
ECU executes may contain valuable IP and know-how, which the car manufacturer wishes to protect. Protection is required both against cloning of the system (anti-cloning protection), as well as against reverse-engineering of the software. Cloning provides the attacker with the ability to create a copy of a component, which would result in loss of revenue to the original manufacturer who cannot sell its own component4. (3) Secure Information & Data logging: Some pieces of information require only protection against modification, while other items in the database also require protection against reading. Secure information logging is to provide a secure database4. (4) Secure Communication: The purpose of secure communication is to prevent an attacker from masquerading and sending false or misleading data to the chip. Secure communication can also enable one-way or mutual authentication between the chip and other entities4. (5) DRM: The device is responsible for enforcing the content access rights, and is liable for commercial loss if broken. Security aspects of DRM include, amongst other things, enforcement of usage rights, key protection as well as content decryption4.
1.5 Solution to Challenges faced in Embedded Security Design:
The solution for the challenged faced in embedded security design is explained below
(1) ECU SOFTWARE INTEGRITY PROTECTION: Secure Key Storage must store the public key and protect it against modifications; otherwise the authentication mechanism can be easily broken. An attacker interested in injecting a new software image can randomly create a new private-public key pair. The attacker then uses the private key to sign the new software image and loads the new software image, new signature and the matching new public key to the system 4. (2) ECU SOFTWARE IP PROTECTION: An attacker might also try to extract IP by probing internal RAM, where the code resides in plain form, using the ECU debug interface. The requirement here is to provide JTAG debug interface protection. Debug port protection is carried out by a dedicated Secure JTAG unit, which resides on the ECU JTAG entry point. Whenever a technician is interested in debugging the ECU, the technician uses the debug tool to ask the on- chip Secure JTAG unit to send a challenge (based on a cryptographic scheme)4. (3) Secure Information & Data Logging: The Secure Storage is based on a unique secret key stored by a Secure Key Storage mechanism and cryptographic algorithms, which provide the security infrastructure4. (4) Secure Communication: public key cryptography methods would provide the most effective way to address this requirement - the target entity holds a private key and the chip is provisioned with the matching public key. Using the public key, the chip is then able to authenticate the target entity. The public key must be kept in Secure Key4. (5) DRM: DRM content arrives encrypted. Therefore, the DRM process concludes when the system obtains the content decryption key. Once the content decryption key is available, it is possible to decrypt the protected content4.
CHAPTER 2
2. Introduction:
Telemedicine system is best example of Applied Medical Informatics. Several physiologic data and Digital images can be transmitted more rapidly and easily than conventional images. In telemedicine expert physicians in tertiary care centres can view a digital image and advice local physicians on the best plan of care without having to move the patient many miles away. This chapter gives connection establishment between the client-server model using both TCP and UDP.
2.1 Functional Requirements and task identification:
Table 2. 1 Requirement specification of telemedicine system
Abbildung in dieser Leseprobe nicht enthalten
2.2 Flow graph for Telemedicine Client-Server System:
Figure 2.1 Shows the flow graph of Telemedicine Client-Server system.
Abbildung in dieser Leseprobe nicht enthalten
Figure 2.1 shows the client/server relationship of the socket APIs for a TCP (left of fig 2.1) and UDP (right of fig 2.1) of telemedicine client server system. Fig shows how the connection is established between the server and client in telemedicine system.
2.3 Flow Chart for Telemedicine Client-Server System:
Fig 2.2 shows the flowchart of the telemedicine server (left of fig 2.2) and telemedicine client (right of fig 2.2). In telemedicine server, the server authenticates the password. If the password is correct then server will display the content of client otherwise the server will not allow client to access the data base. Server reads the selected option and key to encrypt the file and encrypted data will send to client.
In telemedicine client, authentication is accomplished by entering the password by the client to access server. If the password is correct then client can choose the file from the server data base and key to encrypt file in the server. The file received from the server will be decrypted and will be displayed in the client.
Abbildung in dieser Leseprobe nicht enthalten
Figure 2.2 Flow Chart for Telemedicine Client-Server System
2.4 Algorithm to Telemedicine Client-Server System:
Following steps apply to both TCP & UDP.
Step 1: Create socket
Step 2: Binding to created socket
Step 3: Listen to connections // not reqired in UDP
Step 4: Accept a connection // not reqired in UDP Step 5: enter the password in the client.
Step 6: If Password is wrong then Server will not allow to access database.
Step 7: authentication is accomplished by entering the password then client can access the data. base of server, and then display choices to client.
Step 8: client chooses the option by entering file number and key to encrypt the file at server and sent to client.
Step 9: Client receives the file and decrypts it using same key to recover original file.
Step 10: Display the file received.
2.5 Implementation TCP socket between client and server:
TCP socket creation and establishing a connection between client and server is done by basic TCP socket functions.
2.5.1 Implementation at server side:
When server is up and running it creates a socket through which it accepts client connection request. This is done by function socket( ),
sockfd = socket(AF_INET, SOCK_STREAM, 0); This function creates new socket with socket descriptor sockfd.
Next the server sets up its address attributes and binds to the socket. This is done by function bind( ),
bind(sockfd, (struct sockaddr *)&server_addr, SIZE);
After binding to socket server listen to socket for any connection request from clients. This is done by function listen( ),
listen(sockfd, 5);
This function listens on the socket sockfd for connection requests.
If any connection request comes from client, server accepts the request by function
accept( ).
Newsockfd = accept(sockfd, (struct sockaddr *)&client_addr, &client_addr_len);
This function accepts the client request for connection and provides each client with new unique socket descriptor.
After the connection is established between client and server, server can send data to and receive from client by write( ) and read( ) function respectively.
read(newsockfd, (char *)&len, sizeof(short));
write(newsockfd, (char *)&len, sizeof(short));
These functions read from or write data to a particular clients socket descriptor newsockfd.
Fig 2.3 shows the output of tcp server. To execute server, port number has to be provided. TCP listen to client request on this particular port. Server asks to enter user name & password of the user enables to the server to access database from client.
Figure 2.3 Snap shot of output screen shot of TCP Server.
2.5.2 Implementation of Client side:
When the client starts running it creates a socket through which it connects to server and through which actual communication happens. This done by function socket( ), sockfd = socket(AF_INET, SOCK_STREAM, 0);
This function creates socket and give descriptor for the created socket sockfd.
After creating socket client acts up its address attributes and sends a connection request to server. This is done by function connect( ),
connect(sockfd, (struct sockaddr *)&server_addr, SIZE);
Once the connection is established client can send and receive data through the created socket. This can be done by function write( ) and read( ).
read(sockfd, (char *)&len, sizeof(short));
write(sockfd, (char *)&len, sizeof(short));
Fig 2.4 shows the output of tcp client. When client starts running it creates a socket through which it connects to server and through which actual communication happens.
Abbildung in dieser Leseprobe nicht enthalten
Figure 2.4 Snap shot of output screen shot of TCP Client.
2.6 Implementation UDP socket between client and server:
UDP socket creation and establishing a connection between client and server is done by basic UDP socket functions.
2.6.1 Implementation at server side:
When server is up and running it creates a socket through which it accepts client connection request. This is done by function socket( ),
sock=socket(AF_INET, SOCK_DGRAM, 0);
This function creates new socket with socket descriptor sock.
Next the server sets up its address attributes and binds to the socket. This is done by function bind( ),
bind(sock,(struct sockaddr *)&server,length);
After the bind is established in server, server can send data to and receive from client by recvfrom ( ) and sendto( ) function respectively.
recvfrom(int sock, void *buf, int len, unsigned int flags, struct sockaddr *from, int
*fromlen);
sendto(int sock, const void *msg, int len, unsigned int flags, const struct sockaddr *to, int tolen);
These functions read from or write data to a particular clients socket descriptor newsockfd.
Fig 2.5 shows the output of UDP server. To execute server, port number has to be provided. After the bind is established in server, server can send data to and receive from client. Server asks to enter user name & password of the user enables to the server to access database from client.
Abbildung in dieser Leseprobe nicht enthalten
Figure 2.5 Snap shot of output screen shot of UDP Server.
2.6.2 Implementation at Client side:
When the client starts running it creates a socket through which it connects to server and through which actual communication happens. This done by function socket( ), sock = socket(AF_INET, SOCK_DGRAM, 0);
This function creates socket and give descriptor for the created socket sockfd. After creating socket client established up its address attributes and sends a connection request to server. Once the connection is established client can sendto and recvfrom data through the created socket. This can be done by function recvfrom( ) and sendto( ).
sendto(int sock, const void *msg, int len, unsigned int flags, const struct sockaddr *to, int tolen);
recvfrom(int sock, void *buf, int len, unsigned int flags, struct sockaddr *from, int *fromlen);
Fig 2.6 shows the output of UDP client. When client starts running it creates a socket through which it connects to server and through which actual communication happens.
Abbildung in dieser Leseprobe nicht enthalten
Figure 2.6 Snap shot of output screen shot of UDP Client.
2.7 Authentication:
2.7.1 Algorithm at Server side:
Step 1: Enter the user name.
Step2: Compare User name with stored user name in server.
a. If User name matches, proceed to step3.
b. If not matching, exit.
Step3: Enter password to server
c. If password matches, give access to database to client.
d. If not matching, exit.
2.7.2 Algorithm at Client side: Step1. Enter Password
a. If matching, proceed to choose file number from the data base of server.
b. If not matching, exit.
Above algorithm explains the authentication system used in the telemedicine system. At the server side, User who uses server will be provided with the user name and password and he must login with the given user name & password otherwise server will not allow to access the contents of the server. At Client Side, the authentication is accomplished by entering the password by the client to access server, proceed to choose file number from the data base of server. Only when user is authenticated, otherwise server will discard the user request to access
Design and Implementation of Telemedicine Client-Server Model 11
the contents of server. Data base contains x-ray images of patients, drug prescriptions. Entered password will not be visible to others as here getpass () function from unistd.h is utilized. The c code for User Authentication is shown below.
Abbildung in dieser Leseprobe nicht enthalten
2.8 Discussion:
The connection establishment between the client-server model using both TCP and UDP has been achieved. The Internet Protocol is based on the client/server model. Programs called clients initiate connections over the network to other programs called servers, which wait for the connections to be made. The server program is the program that listens for these requests and transmits the correct time. The client-server architecture uses sockets to communicate with each other. The client-server model was originally developed to allow more users to share access to database applications.
CHAPTER 3
3. Introduction:
The branch of cryptology that is dedicated to develop methods that provide these services is called 'cryptography' and systems providing these services are called cryptographic systems. The key part of a cryptographic system is a cryptographic algorithm that essentially provides a method to transform legible information (plaintext) into a form that is protected (ciphertext) with the help of secret information (cipherkey). The simple model given in figure 3.1 describes key components of a cryptographic algorithm. It has become common to personify the users of cryptographic systems. Alice and Bob are users of the crypto system and have access to a secret cipherkey. Oscar represents the malicious attacker who does not have access to the cipherkey, but is generally assumed to have unlimited access to the ciphertext. The process of transforming plaintext into ciphertext is known as encryption and the reverse process is known as decryption. The security of a cryptographic algorithm is defined by the difficulty in which the plaintext can be obtained from the ciphertext without knowing the cipherkey, a process known as 'breaking a cryptographic algorithm'. A second branch of cryptology, called cryptanalysis, concentrates on finding weaknesses of cryptographic algorithms and thus contributes to development of better (more resistant) algorithms5.
Abbildung in dieser Leseprobe nicht enthalten
Figure 3.1 Simple model for cryptographic algorithm5
Designing cryptographic algorithms is a challenging process. The ultimate goal of such an algorithm is to achieve 'unconditional security'. An unconditionally secure algorithm cannot be broken even with infinite amount of computation resources. Unfortunately, the practical realization of such algorithms has proven to be difficult. What are more frequently used are 'computationally secure' algorithms. Breaking these algorithms requires a very large amount of computational resources. As long as the effort required to break the algorithm is sufficiently high, the algorithm is considered to be secure. Most algorithms rely on well studied mathematical problems considered to be difficult to solve. There is, however, no proof that these problems cannot be solved faster, because scientists were simply unable to do so over a long
period of time. Cryptographers live in constant fear of a discovery that provides a faster solution to a mathematical problem serving as a foundation of their algorithm. This is the main reason that most modern cryptographic algorithms are required to go through a public review process. Depending on how the cipherkey is managed, the cryptographic algorithms can be classified into publickey algorithms and privatekey algorithms. Publickey algorithms use a cipherkey that consists of two parts. Bob makes the public part of the cipherkey known to the whole world, and keeps the second part secret. When Alice wants to send a message to Bob, she uses this public key to encrypt the message. The public key algorithms are designed in a way to enable a decryption of the ciphertext only with the second (secret) part of the cipherkey. Privatekey algorithms, on the other hand, rely on a cipherkey that both Alice and Bob know and keep secret. Publickey algorithms are usually computationally intensive and are therefore not suited for secure transmission of lengthy messages. Privatekey algorithms are suited for bulk transmission, but it is a challenge to distribute the required secret cipherkey. Typical secure applications on the Internet use a public key algorithm to negotiate a sessionkey between Alice and Bob. This sessionkey is then used as the cipherkey of a privatekey algorithm to transfer data between Alice and Bob5.
Privatekey cryptographic algorithms that use the same cipherkey to process multiple plaintext ciphertext pairs are called block ciphers. Common cryptographic algorithms like DES AES and Rijndael fall into this category5.
This chapter gives an implementation of the TCP and UDP client-server model using AES algorithm in Telemedicine system. The data transmitted must be secured by authenticating, encrypting the data and decrypted before viewing on the client side and image or text is displayed in the client. Implementation is done in C. Implemented methods are tested for its success5.
3.1 AES algorithm
The AES algorithm is a block-cipher operating on 128-bit data blocks supporting three different cipherkey lengths of 128, 192 and 256 bits. These three flavours of the AES algorithm are also referred to as AES-128, AES-192 and AES-256, for 128, 192, and 256-bit cipherkeys, respectively. An AES encryption process consists of a number of encryption rounds (Nr) that depends on the length of the cipherkey. The standard calls for 10 rounds for AES-128, 12 rounds for a AES-192, and 14 rounds for a AES-256. During encryption, each round is composed of a set of four basic operations. The decryption process applies the inverse of these operations in reverse order. Figure 3.2 shows the basic structure of the AES encryption and decryption5.
Abbildung in dieser Leseprobe nicht enthalten
Figure 3.2 Basic structure of the AES algorithm: encryption (left), decryption (right)5.
3.2 AES encryption and decryption:
Implementation of AES encryption and decryption is shown in figure 3.3:
Abbildung in dieser Leseprobe nicht enthalten
Figure 3.3 Secure data transmission using AES encryption and decryption.
The client-server model was originally developed to allow more users to share access to database applications. The data must be secure, when the data is transmitted from server to client, security must ensure that data will not be damaged by attackers and protects against danger, loss, and criminals. Even if someone tries to hack the data content of file should not be revealed to the attacker. So it is necessary to encrypt the data before transmitting the file using encryption methods. The encryption method used in server and client model is AES (advanced encryption standard) which is used for encryption and decryption of key and Xor encryption is used to encrypt and decrypt the x-ray images of patients, drug prescriptions.
The secure data transmission using AES encryption and decryption is shown fig 3.3. The Advanced Encryption Standard (AES) specifies a FIPS-approved cryptographic algorithm that can be used to protect electronic data. The AES algorithm is a symmetric block cipher that can encrypt (encipher) and decrypt (decipher) information, encryption converts data to an unintelligible form called ciphertext; decrypting the ciphertext converts the data back into its original form, called plaintext. The AES algorithm is capable of using cryptographic keys of 128, 192, and 256 bits to encrypt and decrypt data in blocks of 128 bits. The encryption and decryption of a plain text or a video stream can be done in two ways: (1) Secret key encryption: a single secret key can be used to encrypt and decrypt the file. Only the sender and the receiver have this key. (2) Public key encryption: there are two keys, one for encryption and the other for decryption. The public key, which is known for all senders, is used for encryption, while the private key, which is owned only by the receivers, is used for decryption. AES and XOR algorithms are used to encode and decode the image. Same encryption and decryption is utilized both in UDP & TCP.
3.2.1 Implementation of AES algorithm at server side in C code is show below:
Abbildung in dieser Leseprobe nicht enthalten
KeyExpansion(); // The KeyExpansion routine must be called before encryption.
Cipher(); // The next function call encrypts the PlainText with the Key using AES algorithm
3.2.2 Implementation of AES algorithm at client side in C code is show below:
Same code as used in server above instead of cipher(), the InvCipher(); is used The algorithm of cipher(), InvCipher() and KeyExpansion is shown in section 3.2.3:
3.2.3 Algorithm of cipher(), InvCipher(), KeyExpansion and XOR:
Abbildung in dieser Leseprobe nicht enthalten
[...]
- Citation du texte
- Manjunath Basavaiah (Auteur), 2011, Design and Implementation of Telemedicine Client-Server Model using Encryption and Decryption Algorithm in Single Core and Multicore Architecture on LINUX Platform, Munich, GRIN Verlag, https://www.grin.com/document/188096
Textes similaires
Devenir un auteur
Commentaires