Evaluación

A GTF peer interacts with other GTF peers and WS-Tracker. Similar to security issues at WS-Tracker Service, identifying GTF peers (authentication), deciding who is permitted to download/upload which content with which rights (authorization), and providing secure communications between the entities are the primary issues and challenges that we must face.

To address those security challenges, we followed a security infrastructure model similar to GSI to build authentication, authorization, and secure data transmission services in a GTF peer. This security infrastructure is built on one-way hash function, security credentials, symmetric and asymmetric keys (i.e., certificates, public-private keys, and secure keys). When an owner of a GTF peer wishes to share their content, their GTF peer generates a checksum for each piece, using one-way hash function. All of these hash code for each piece are used by downloading peers to verify the integrity of the data they receive. To support authentication, integrity protection,

the Java Authentication and Authorization Service (JAAS) and the Java Secure Socket Extension (JSSE).

We explained how the security issues between a GTF peer and the WS-Tracker service were handled in the previous section. To deal adequately with the security matters between GTF peers, a user needs to obtain both public-private key pair, and X.509 certificate. Nowadays because of availability of myriad software tools to generate public-private key pair, it is a simple process. As a result of this, it is user’s responsibility to generate their public-private key and initiate the X.509 certification request process. Upon user’s X.509 certification acquisition, it satisfies all the preconditions, as shown in Figure 7 -33, for secure communications taking place among the GTC Clients and WS-Tracker.

Figure 7-33 Security credentials and security mechanism between GTF Peers

Although secure data transmission is optional, GTF peer utilizes symmetric block ciphers to encrypt every single block of data to send data over a secure channel. A common cipher key -secret key- is needed at both ends for encrypting and decrypting processes. Hence, a secret key, unique for each content, is generated by the original

owner of content when the .torrent meta-file of the content is constructed. This secret key is distributed securely to other GTF peers interested in the same content via the TLS encrypted communication at which authentication and authorization activities take place. If secure data transmission is requested, GTF peers use the same key for the same content to encrypt and decrypt exchanged data. Note that protection of those credentials is user’s responsibility as well.

As it is illustrated in Figure 7 -31, following the step 6 or 6’, the downloading GTF peer B in organization B asks for and receives the metadata file (.torrent file) of the content since its owner scheduled that task at step 3 or 3’. Subsequently, it starts establishing connections with other GTF peers whose IP address and port number information is acquired from the .torrent file that is obtained from WS-Tracker. At

Figure 7-34 Authentication, authorization and exchanging secret key processes between two GTF Peers

step 7, GTF Peer B initiates authentication and authorization procedures because each peer has to be authenticated and authorized before starting the content download process. Both GTF peers use their credentials to authenticate themselves to other party. Upon receiving the authentication request of GTF Peer B, GTF Peer A verifies the access rights of GTF Peer B by using the Access Control List Registration Table (ACLRETAB). GTF Peer A terminates the GTF Peer B’s connection promptly if either one of the authentication or authorization process fails. The internal mechanism of

authentication, authorization, and exchange of secret key between two GTF peers is illustrated in Figure 7 -34.

Table 7-33 Summary of security issues between GTF components

Security Issues User  The CCM The GT Client  The GT Client Authentication User uses username and

password are to access the CCM.

Credentials (certificates, public-private keys)

Authorization Content owner decides who is authorized to what

It enforces the authorization settings provided by owner through the CCM and the WS-Tracker service

Message Integrity

SSL/TSL used during the communication

Content data transferred with/without encryption. Secret key is employed for secure data transfer.

After a successful authentication and authorization operation, GTF Peer A allows GTF Peer B to start the process of actual data movement, occurring at step 9, by passing data port number, secret key, and pass-phrase. Secret key is used for data encryption and decryption if one of the peers requires the transmission of data over a secure channel. Pass-phrase is used to revalidate the identity of GTF Peer A on data port. Upon arrival of secret key and pass-phrase, GTF Peer B passes this information to its Data Sharing Module to commence the actual data transfer process. Then, the Data Sharing Module of GTF Peer B connects to the Data Sharing Module of GTF Peer A

and starts downloading actual data. Finally, all downloaded data segments are coalesced at step 9’ after downloading all pieces successfully (Refer Section 4.5). We also summarized the major security concepts used in the GTF in Table 7 -33.