electronics projects pune

Electronics Project based on security

Laptops are vulnerable to theft and loss due to their small size and the characteristics of their common usage environment. Since they allow users to work while away from their desk, they are most useful in public locations and while traveling. Unfortunately, this is also where they are most at risk. Existing schemes for securing data either do not protect the device after it is stolen or require bothersome re-authentication. 

So how does a machine know who is using it? Current systems authenticate their users infrequently, and assume the user’s identity does not change. Such persistent authentication is inappropriate for mobile and ubiquitous systems, where associations between people and devices are fluid and unpredictable. We solve this problem with Transient Authentication, in which a small hardware token (Mobile Phone) continuously authenticates the user’s presence over a short-range, wireless link. When the user departs, the token and device lose contact and the device secures itself. We show how to leverage this authentication framework to secure folders on laptop into which secrets may creep. In our model of authentication, a user uses his Bluetooth-enabled mobile phone, which works as an authentication token that provides the authentication for laptop over a short-range wireless link. The user authenticate to the mobile phone infrequently. In turn, the mobile phone continuously authenticates to the laptop by means of the short-range, wireless link. 

INTRODUCTION 

Powerful and affordable laptops have brought users an unprecedented level of convenience and flexibility. Laptops let users work anywhere, anytime. Unfortunately, physical security is a major problem for these devices. To be portable, they must be lightweight and small-sized. Since they are designed for mobile use, they are often exposed in public places such as airports, coffee houses, and taxis, where they are vulnerable to theft or loss. Along with the value of lost hardware, users must worry about the exposure of sensitive information. People store vast amounts of personal data on their laptops and the loss of a device may lead to the exposure of credit card numbers, passwords, client data, and military secrets. 

Laptops sensitive data can also be protected by using encryption, but the challenge in device security is not encrypting data but authenticating the current user. A device must obtain proof of the user’s identity and authority before granting access to data. This proof could take the form of a password, a smart card inserted into a reader, or bio-metric data from a fingerprint or iris scanner. Unfortunately, these forms of authentication are infrequent and persistent. Should a device subsequently fall into the wrong hands, an attacker could act as the real user, subverting encryption for the duration that this authentication holds. But, how often must a user authenticate her? One might require users to re authentication each time the device performed any operation on sensitive data. This would quickly render the system unusable and many users would disable the authentication system out of annoyance. Another mechanism would require the user to “unlock” the device once at boot. This would enhance the user experience but leave data vulnerable if the device were lost or stolen. These two models highlight an inherent tension between security and usability. While data should only be accessible when its authorized user is present, it is obtrusive to continually ask for proof. 

Our new model, Transient Authentication, resolves this tension. Users can have a small token (e.g., Mobile Phone) and modest computational resources. It constantly authenticates to devices on behalf of the user. The limited radio range (several meters) serves as a proximity cue, letting a device take steps to protect its data when the user leaves the physical area. Since users have the token which is been frequently used by the user, it is far less likely to be misplaced or stolen than is a laptop. 

Armed with this authentication data from the mobile phone, laptop protects data when the user departs by encrypting, overwriting, and/or flushing it. Cryptographic file systems secure data in persistent storage, but the unique characteristics of laptops make protecting data in other memory locations critical as well. Batteries and wireless network links allow devices to continue running while traveling and in public places. This is precisely where they are most vulnerable to loss or theft. Some processes can safely continue while the user is absent, either because they do not handle sensitive data or because they secure their secrets themselves. Such applications use application-aware protection API to access authentication data and token services.

TRANSIENT AUTHENTICATION :

Transient Authentication is founded on the following four design principles:

Tie Capabilities to Users.                                                               

The laptops should only perform sensitive operations when the user is present. Thus, all encryption keys must reside solely on the user’s mobile phone, which is in her possession at all times and is therefore far less likely to be stolen or misplaced. For performance, credentials may be temporarily cached at the laptops, but must be discarded whenever the mobile phone is not present. 

Do No Harm. 

Users quickly disable inconvenient security mechanisms. But, anecdotal evidence shows that users are willing to infrequently reenter passwords. Transient Authentication requires user participation that is no more burdensome. Users will also quickly disable our system if they notice poor performance. To ensure adoption, the additional overhead of key authentication, communication, and data encryption must not be excessive. 

Secure and Restore on People Time. 

When the user departs, the device must secure itself before an attacker would have the chance to physically extract any information. This time window is on the order of seconds, not milli or microseconds. Conversely, when a user walks back to use the device, the token will regain wireless contact while she is still meters away. This gives the system several seconds to restore the device’s state.

Ensure Explicit Consent. 

The device must not take any sensitive action without the user’s consent.

Transient Authentication must ensure that both

1) The user’s laptop is indeed talking to her mobile phone and

2) Her mobile phone is not communicating with any other devices without her knowledge.

    To do so, users explicitly bind tokens to devices through an exchange of public keys that establishes a pair wise trust relationship. To limit the consequences of mobile phone loss, users authenticate themselves to their mobile phone daily.

1. AUTHENTICATION SYSTEM DESIGN

Mutual authentication:

The mutual authentication is the first step in the authentication system. In this step the system perform a challenge-response function between the laptop and mobile phone in order to authenticate each other based on public key system. The mobile phone and has predefined key pair.

 User authentication:

Authentication between user and his/her mobile phone both infrequent and persistent, when the mobile phone asks for user authentication this authentication holds for 24 hours, if failed to do so user cannot access his/her data what ever the state it would be.                                                

 User Authentication: User has to re-authenticate once in 24 hours to access the data as per persistent authentication.

Session key creation:

Session key is uses to encrypt all laptop-mobile phone communication, once session key is established, all information that transfers over the wireless link will not be in clear text format; instead it will be encrypted and authenticated using a session key. The creation of symmetric session key is done based on Diffie-Hellman Key Exchange Agreement/Algorithm.

Disconnection and re connection:

 The system periodically sense mobile phone to ensure that the user is still present, when the mobile phone is out of the range the laptop take step to secure it self. There are two reasons why laptop cannot receive a response from the mobile phone, firstly the mobile phone and the user are truly being away, or secondly the link may have dropped the packet. For the latter the system uses expected round trip time between laptop and mobile phone, because this is a single, uncontested network hop, this time is relatively stable.  

Encryption and Decryption process:

The system uses the U.S. government standard 128-bit advanced encryption standard to encrypt all laptop-mobile phone communication, we chose this method because it is the current advanced encryption standard chosen by the National Institute of Standards and Technology and it is fast enough to run efficiently with limited memory resources and processing time.

CONNECTION ESTABLISHMENT

Connection establishment at laptop side:

            The laptop acts as client side in the piconets, its communication consist of initializing the Bluetooth stack, discovering mobile phone that is in proximity, open and close and initiate connections and perform security application I/O messages.

            Bluetooth initialization typically entails setting the device’s name, security settings and/or turning the Bluetooth radio on/off. These a fore mentioned steps are done via what is referred to as the Bluetooth control centre (BCC), which typically are a set of control panels that services as the central authority for local Bluetooth device settings.

            Before creating the connection the application retrieve local device information that uses for creating connection. Creating Bluetooth connections is done using the logical link control and adaptation layer (L2CAP) of the Bluetooth protocol stack. L2CAP does a simple Ns lookup and gets the address of the mobile phone (server or master) and tries to establish a logical connection with the L2CAP of the master (mobile phone) through the host controller interface (HCI) layer below. After creating the connection the application performs the security function I/O messages. 

 Connection establishment at mobile phone side:

The mobile phone acts as server side in the piconets, it performs same client functions except that instead of initializing and opening connection it creates a server connection using the L2CAP and waiting for connections, accept and open connections and perform security application I/O messages.

Before creating the connections the application get the local device and make it to discoverable however the client (laptop) can establish a connection to it. When mobile phone receive a L2CAP connection request it accept and open connection and start to perform security I/O messages and manage connection according to its results.