Architecting a Secure Enterprise Data Sharing. (Domain : Secure Computing)

03. Architecting a Secure Enterprise Data Sharing. (Domain : Secure Computing) 

ABSTRACT:

This paper analyzes secure data sharing outside the security domain. There is a high demand for accessing multiple levels of sensitive data at the edge; however the threat at that location is higher compared to the core enterprise environment. This paper investigates the requirements, technologies and risk mitigation techniques for securely sharing information with the tactical user while protecting the data and the information systems from intruders and malware. The new Enterprise Architecture needs to eliminate the stovepipe architectures and open the doors to share information across traditional and non-traditional domain boundaries

EXISTING SYSTEM:

•         Traditionally, information security has been purely defensive. Firewalls, Intrusion Detection Systems, encryption; all of these mechanisms are used defensively to protect one's resources.

•         A variety of detection tools exist such as Intrusion Detection systems (IDS) and firewalls, but the main problem is that they only react on reconfigured and therefore known attacks.

•         In an existing system that will produce only the simulation result.

•         There is no secured architecture for data sharing.

•         Existing system can only run on single system.

PROPOSED SYSTEM:

•         In order to deal with these challenging and complex ideas on information sharing, we must consider one of the premier drivers that provide the infrastructure to achieve this notion of Core to Edge security to enable information sharing.

•         Proposed system can note the IP address of Hackers and can identify what type of file they want to access and what password and key was given by hackers to access the file.

•         This system can produce the real time result.

•         We can run it on more than one system without changing, and can run in single system too.

The primary purpose of a Honey net is to gather information about threats that exist. In the proposed system we does not use a real time Honey net, But uses a offline type of honey pot. Which just view the old collected data.

HARDWARE SPECIFICATION

The required hardware interfaces are LAN and a standard PC.

Processor Type                 :                  Pentium -IV

Speed                                :                  2.4 GHZ

Ram                                  :                  128 MB RAM

                  Hard disk                          :                  20 GB HD

SOFTWARE SPECIFICATION

                  A tool is used for capturing packets from network.

Operating system     :  Windows - XP

Tools                        :  Eclipse

SDK                         :  JDK.1.5.0

Database                  :  MS-Access

MODULES

1. Key generation

2. Construct botnet (Proposed Secured System for Data Sharing)

3. Monitoring

Key generation

Command Authentication

Compared with a C&C botnet, because bots in the proposed botnet do not receive commands from predefined places, it is especially important to implement a strong command authentication. A standard public-key authentication would be sufficient. A botmaster generates a pair of public/private keys, hKþ;K_i, and hard codes the public key Kþ into the bot program before releasing and building the botnet. There is no need for key distribution because the public key is hard-coded in bot program. Later, the command messages sent from the botmaster could be digitally signed by the private key K_ to ensure their authentication and integrity. This public-key-based authentication could also be readily deployed by current C&C botnets. So botnet hijacking is not a major issue.

Implementation of Individualized encryption key and service port

In the proposed botnet, each servent bot i randomly generates its symmetric encryption key Ki. Suppose the peer list on bot A is denoted by LA. It will not only contain the IP addresses of M servent bots, but also the symmetric keys used by these servent bots.

Thus, the peer list on bot A is:

LA = { (IPi1, Ki1), (IPi2, Ki2), ¼(IPiM, KiM)}

Where (IPij, Kij) are the IP address and symmetric key used by servent bot ij. With such a peer list design, each servent bot uses its own symmetric key for incoming connections from any other bot. This is applicable because if bot B connects to a servent bot A, bot B must have (IPA, KA) in its peer list.

 This individualized encryption guarantees that if defenders capture one bot, they only obtain keys used by M servent bots in the captured bot's peer list. Thus the encryption among the remaining botnet will not be compromised.

DATA ENCRYPTION / DECRYPTION:

The Blow fish involves replacing each letter of the alphabet with the letter standing k places further down the alphabet.

Encryption:
Blowfish is a Feistel network consisting of 16 rounds (see Figure 1). The input is a 64-bit data element, x.

Divide x into two 32-bit halves: xL, xR

For i = 1 to 16:

xL = xL XOR Pi

xR = F(xL) XOR xR

Swap xL and xR

Swap xL and xR (Undo the last swap.)

xR = xR XOR P17

xL = xL XOR P18

Recombine xL and xR

Function F (see Figure 2):

Divide xL into four eight-bit quarters: a, b, c, and d

F(xL) = ((S1,a + S2,b mod 232) XOR S3,c) + S4,d mod 232

Decryption
It is exactly the same as encryption, except that P1, P2,..., P18 are used in the reverse order.

This algorithm used to encrypt the all the data before going to send to the user.

Using the private key k it is decrypted on the end user side. The user who knows the private key can only decrypt the data.

REFERENCE:

Bassam S. Farroha and Deborah L.Farroha, “Architecting a Secure Enterprise Data Sharing Environment to the Edge”, IEEE International Conference on Systems Conference (SysCon), 2011.

 

Click Here: for Downloading Base Paper