In the course of development of computer technology, the era from mainframe computer to personal computer is the changes of era of experience from mainframe computing to desktop computing model, which greatly enhanced the productivity and promote human society development. Of course, compared with the mainframe model, the desktop computing model has great progress. But it also brings many restrictions to users and makes it difficult to really integrate computer into people's life and work that has become an obstacle to the development of computer and the progress of human society. So that, the pervasive computing concept emerged as the times require. The thinking of pervasive computing was put forward by American scientist Mark Weiser in his book "The Computer for the 21st Century" in 1991. The ultimate goal of pervasive computing is the realization of computing people-oriented and ubiquitous, making the computer disappear from the eyes of the people, and people can't feel the presence of computer, so that people can only focus on the task rather than the tool - computer itself [1]. In this paper we organize and present various security challenges associated with the pervasive computing and also proposed some countermeasures. In particular, we look at both
ARP poisoning and Mac spoofing attacks. And Provide the JXTA Security Framework for pervasive computing using JXTA-Overlay.
II. LITERATURE REVIEW
A. Pervasive Computing Architecture
Our architecture is mainly composed of core services implemented with component and middleware technologies. The application objects can communicate with Service Manager, which is one of core components and responsible for providing invocation interfaces of various service components for application objects [2]. Core components encompass several core services, such as service discovery service, secure control service, trust management service, context service, communication management service, etc. Communication management agent is responsible for communicating with network infrastructure or protocols, which may be frequently changeable in pervasive computing environments. The core components in our resented architecture make fully use of middleware technology, all the components in the architecture can be encapsulated into different types of middleware, such as service discovery middleware, context middleware, security control middleware, trust management middleware, and so on, then, theses various middleware services will be integrated to construct a complete system architecture for pervasive computing. The architecture presented by us is shown in Figure 1. In the future, if there appear new kinds of middleware that can provide other various services, they can be added into the architecture easily. Therefore, the architecture is flexible and extensible.
Service discovery service
Service discovery is an important problem for providing services in pervasive computing environments. It is an essential component in the system architecture for pervasive computing.
Context service
This component can collect situational information, including historical, current, and future static information or dynamic information about users and resources in pervasive computing environment. Then, it can provide gathered information for the service discovery component and the trust management component to help make decisions.
Security control service
Security control is another important problem in system architecture for pervasive computing. Due to the dynamic characteristics of frequently changeable pervasive computing environment, it is indispensable to provide certain secure control mechanisms.
Trust management service
In this architecture, we will construct a novel trust model in which trust relationship will be based on historical interaction information, time information, and other parameters. When there comes a new visitor, it could decide whether to accept it or not by depending on the calculated trust value on the visitor. The trust model is still under pondering up to now
Communication management agent
Agent technology has many advantages in ad hoc network, such as mobility [5], intelligence, sociality, etc. These virtues are very beneficial in the communication process for the system architecture for pervasive computing
Service manager
The service manager is responsible for the communication between core components and application objects. It can provide the unified invocation interfaces for various components in the architecture. By tracking the service manager, application objects can get the access interfaces for the requested services facilely.
III. SECURITY ATTACK-ARP POISONING PROCESS
ARP poisoning is an effective form of attack by a hacker, where by he can masquerade a network and fool the sending host. This happens because the ARP broadcast reaches him too once connected to the wired LAN or listen to wireless LAN. Later, he can reply the ARP request with a forged ARP response putting his computer's MAC address in that. The sending host is thus fooled into sending all the packets to the hacker's computer which can be forwarded to the receiving host, if needed. The attacker can also poison the receiving host and get a reverse path going. The attacker thus realizes a two way man in the middle, where he can forward the received packets to the correct destination after inspecting and possibly modifying them.
Figure 2. The ARP poisoning mechanism
IV. SECURE UNICAST ARP (S-UARP) PROPOSAL
Here each host has a public/private key pair certified by a local trusted party on the LAN, which acts as a Certification Authority. Messages are digitally signed by the sender, thus preventing the injection of spurious and spoofed information. It has been implemented also in Linux .The S-UARP proposal we make is unicast in nature and have different options for security implementation. Many organizations would have implemented a DHCP server for dynamic IP address assignment to individual machines in a LAN. Hence the DHCP server can be configured to have the MAC-to-IP address mapping or vice-versa for all the computers/hosts under its domain. We propose to extend the DHCP protocol to handle Secure Unicast Address Resolution Protocol (S-UARP) packets. We denote such a server as DHCP+ server from now on. The DHCP relay agent also needs to be modified to forward the S-UARP request/response messages. When using dynamic IP addressing using DHCP, the DHCP+ server stores the mapping of IP to MAC address as it leases out the IP address to the requesting hosts. We are not dealing with static IP addressing option here. But some suitable modification to this protocol can make it suitable for static addressing too [4].
S-UARP Protocol :
The S-UARP protocol is described as follows in 3 steps:
1. A ïƒ DHCP+ : S-UARP_req
2. DHCP+ ïƒ A : S-UARP_res + MIC
3. A ïƒ DHCP+ : (ACK) KSA
A simple example and explanation to show how this can be implemented with DES algorithm is as follows:
1. When a host A wants to communicate to host B, it sends a S-UARP request packet (unicast packet) to the DHCP+ server (which answers the S-UARP packets), instead of sending a broadcast to all. We assume that the secret hashing key (KSA) is distributed between the client and the server, using private-public key mechanism or any other secure mechanism.
2. The DHCP+ server encrypts the response message using DES with cipher block chaining (CBC). It cuts the message (S-UARP_res) into predetermined-sized of i blocks (where i =1, 2… n). Use the CBC residue (that is the last block output by CBC process) as a message integrity code (MIC). This MIC would act as a checksum. The plaintext message plus the MIC would be transmitted to the host (receiver) or A. i.e.DHCP+ Server ïƒ Host A: Transmit S-UARP response (plain text) + MIC.
3. Once the UARP response is received, host A checks for validity by using its secret key. The receiver (Host A) encrypts the plaintext SUARP_ res using DES that it received with the shared secret key and do the hashing process to produce similar MIC (say, MIC*). Finally it checks the CBC residue or MIC. If MIC = MIC*, the message is a non-tampered in transit. We then call it Integrity Check Pass (ICP) state. Otherwise it is Integrity Check Fail (ICF) state and is discarded. Finally, the host A sends an encrypted acknowledgment (ACK) KSA to the server. ACK contains the timestamp ta generated by the host A to ensure that the message is fresh and is not a replay.
V. JXTA ARCHITECTURE
In a peer-to-peer network, all involved parties share resources and collaborate in order to provide basic services, such as content, processing or messaging. Under this scenario, it is also assumed that all peers have equivalent capabilities, and a central server with more processing power is no longer necessary. JXTA is a set of open core protocols that enable the creation of such networks. JXTA's core protocols allow peers to cooperate and form autonomous peer groups transparent to their location, as well as providing the necessary services in order for any other protocol to be used in JXTA applications and operate
Figure 3. The flowchart showing the procedure
of S-UARP operation
within the network. Peers may use such protocols in order to advertise and discover resources, join peer groups and dynamically route messages across multiple network hops. Since, ultimately, every JXTA application must rely on the use of its core protocols in order to interact with other peers within the network, it is very important to provide capable methods to secure them in order to avoid possible attacks. The current JXTA reference implementation addresses some of this problem, but the provided methods are not fully satisfactory, as they do not fully comply with the JXTA specification ideary of XML data formatting and relies on the existence of a party that must be trusted by all peer group members. The standard security threats to be addressed under a P2P environment can be divided into two different groups: passive and active ones. Passive attacks are those in which the attacker just monitors activity and maintains an inert state whereas in active attacks, communications are disrupted by the deletion, modification or insertion of data.
Figure 4. JXTA protocol layers and protocols
VI. AN OVERVIEW OF JXTA CORE PROTOCOL SECURITY
JXTA's endpoint communication is structured in a classical layered approach; core protocols acting as a gateway to networking operations under a peer-to-peer environment (see Figure 4). This provides an abstraction layer to both JXTA's own services and custom made application dependant ones (operating at the upper Services layer), enabling the deployment of services in a transparent manner to the real underlying transport methods or topology At the Peer layer, the higher level core protocols (PIP, RVP, PBP and PDP) allow services to publish, locate and exchange resources. The Endpoint layer manages routing and addressing, via the ERP protocol, and specifies the format for all query-response exchanges, using the PRP protocol
A. Core protocol privacy
Core protocol privacy is achieved by encrypting the XML message content Messages are selectively encrypted using a wrapped key encryption scheme (such as the one defined in [12]). For each message field to be encrypted, a symmetric key is generated and used to encrypt the field. The symmetric key is then encrypted (wrapped) using each recipient's public key, obtaining a set of encrypted keys, that can only be accessed by only one of the recipients This scheme is applied at the message layer according to the profile shown in Figure 3. Wrapped keys are included into the encrypted message by encapsulating the original message into an Encrypted Message XML element and introducing an additional XML element as a sibling, the KeyList element.
Figure 5. Message encryption profile
By using this XML profile and message schematics, it is possible to accommodate selective entry encryption. Since the final encrypted data is sent to wire transport protocols as a standard JXTA message, encrypted fields become transparent to its basic operation.
XML Listing 2 - Selectively encrypted message :
<?xml version="1.0" encoding="UTF-8"?>
<xmlsecure:EncryptedMessage>
<jxta:ORes>
<ResolverQuery>
<HandlerName>urn:jxta:uuid-DEADBEEF...05</HandlerName>
<QueryID>0</QueryID>
<HC>0</HC>
<SrcPeerID>urn:jxta:uuid-59...503</SrcPeerID>
<xenc:EncryptedData xmlns:xenc="...xmlenc#"
Type="...xmlenc#Element">
<xenc:EncryptionMethod
Algorithm="...xmlenc#aes128-cbc"/>
<ds:KeyInfo xmlns:ds="...xmldsig#">
<ds:KeyName>Message
Key ID</ds:KeyName>
</ds:KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>Pr...It/4</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
</ResolverQuery>
</jxta:ORes>
<KeyList>
<KeySet>
<xenc:EncryptedKey xmlns:xenc="...xmlenc#">
<xenc:EncryptionMethod Algorithm="...xmlenc#rsa-1_5">
<ds:KeyInfo xmlns:ds='...xmldsig#'>
<ds:KeyName>urn:jxta:uuid-59...C03</ds:KeyName>
</ds:KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>N9...9w==</xenc:CipherValue>
</xenc:CipherData>
<CarriedKeyName>Message
Key ID</CarriedKeyName>
</xenc:EncryptedKey>
<xenc:EncryptedKey xmlns:xenc="...xmlenc#">
<xenc:EncryptionMethod Algorithm="...xmlenc#rsa-1_5">
<ds:KeyInfo xmlns:ds='...xmldsig#'>
<ds: KeyName>urn: jxta:uuid-59...F03</ds:KeyName>
</ds:KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>A3...7f==</xenc:CipherValue>
</xenc: CipherData>
<CarriedKeyName>Message
Key ID</CarriedKeyName>
</xenc: EncryptedKey>
</KeySet>
</KeyList>
</xmlsecure: EncryptedMessage>
B. Core protocol authenticity and integrity
Authenticity and data integrity (as well as non-repudiation) are provided to core protocols by using XML signature (xmldsig) at the messaging layer. Since the process is very similar to the method proposed in [10] for advertisement authenticity, a general outline will be presented. However, it has been specifically adapted for core protocol messaging. In this proposal, a detached signature is used within the message body, as shown in Figure 5.
The XML signature is included as a message signature, just as is the case in CBJX, but instead of a self-defined single Signature element, a full xmldsig signature is included. In contrast with CBJX, no additional encapsulation is needed, since the XML signature contains all needed information related to the security layer [7]. As a result, messages generated using this method may be processed even by peers which do not support signatures (they are able to decode the original message and ignore the signature).
Figure. 6. Xmlenc encryption profile
Figure 7. Xmlsig detached signature profile
VII. PROPOSED SYSTEM ARCHITECTURE
The JXTA Overlay project is an effort to use JXTA technology to provide a generic set of functionalities that can be used by developers to deploy P2P and pervasive applications Peer-to-peer (P2P) have become highly popular in recent times due to its great potential to scale and the lack of a central point of failure. Just as the popularity of P2P systems has risen, so has concerns regarding their security, specially since it is no longer possible to trust a central server which capitalizes all security operations. As P2P applications move from simple data sharing to a broader spectrum, they become more and more sensitive to security threats and it becomes very important for current P2P platforms to include security mechanisms that can fit into a broad set of scenarios [8]. Even at the cost of some impact on performance, a security baseline must be kept in any P2P system in order to ensure some degree of correctness even when some system components will not act properly.
JXTA-Overlay Overview
End-users connect to the JXTA-Overlay network by authenticating using a username and password. Once the authentication process is successfully completed, they are organized into different overlapping groups, so only members of the same group may interact. It is also important to take in to account that JXTA-Overlay end-users are mobile, they may connect at different times using different client peers, as well as may be connected through several client peers at the same time. A client peer represents an application, which end-users use to communicate and share resources between themselves, effectively acting as end-user proxies within the JXTA-Overlay network [9]. They forward end-user data to client peers that belong to end-users of the same group and authentication data to a broker. A client peer is assumed to belong to the same groups as its current end-user. Brokers control access to the network, requesting end-user authentication, and help client peers interact between themselves by propagating their related information. Brokers are very important since they exchange information about all client peers, maintaining a global index of available resources, thus allowing all peers to find network services. Brokers also act as beacons which client peers which have recently gone online use to join the network [10].
Figure 8. JXTA-Overlay architecture.
Figure 9. Security architecture for JXTA-Overlay
VIII.CONCLUSION AND FUTURE WORK
The new S-UARP protocol is more efficient in reducing broadcast congestion in network, since the SUARP request is unicast and directed to only DHCP+ server. The protocol is also more secure and it is quite difficult for an attacker to do ARP poisoning attack, especially on the more secure versions of S-UARP. We need for new security paradigms in the pervasive computing world.
A new proposal for core protocol messaging security in JXTA has been presented. Its main contributions are threefold. First of all, the proposed method provides two flavors of security services in order to thwart network threats: on one side, data privacy, and on the other side, authenticity, integrity and non-repudiation.
Further work includes using the proposed security framework to define secure primitives for those interactions which are deemed sensitive to attacks, in a manner that they complement existing ones, but not forcibly replace them. Of special note are those of the executable set of primitives, related to remote code execution.
