Final Year Project Interim Report

Transcription

1 2013 Final Year Project Interim Report FYP12016 AirCrypt The Secure File Sharing Platform for Everyone Supervisors: Dr. L.C.K. Hui Dr. H.Y. Chung Students: Fong Chun Sing ( ) Leung Sui Lun ( ) January 2013 D e p a r t m e n t o f C o m p u t e r S c i e n c e T h e U n i v e r s i t y o f H o n g K o n g

2 Abstract With the increasing usage of online file sharing platforms, the security of those currently provided services becomes a hot topic among the users. Files are more easily to be shared however their confidentiality is also dropped. Some file sharing platforms allow user to download file even without the need to input any password. AirCrypt has been developing to provide users an online storage and sharing platform and, at the same time, with sufficient security means. Making use of an NFC supported mobile device and a NFC tag, user can access their files in the server securely and conveniently. Sharing of file is also protected by access control. Security, user-friendly and cross-platforms are the main purpose of AirCrypt. 2

3 Contents 1. Background Objectives System Design Security Features Other Features System Architecture Main Application Flow Current Progress Android App Server and Client Program Development Tools Limitations and Difficulties Encountered Limitations Difficulties Encountered and Our Solutions Work Division Future Plan

4 1. Background In this modern year, computer is important device for people to communicate with each other and store information. Files like photos, music, videos, and documents are all stored as electronic copies. With the increasing usage of internet, people would like to share files with the others through the internet. Traditionally, user would share his/her file by sending the file directly to another, for example, through . However, it is quite time-consuming as user has to upload the file to the server every time. It may take a lot of time if there are many files to be sent or the file size is too large. And it is also inconvenient when sharing the file to a group of people. In recent year, file sharing platforms such as Dropbox are very popular as they allow users to share files easily. User just needs to upload the file to the platform once. After that, they can share the file easily by disturbing an URL of the file. People also make use of these platforms as an online storage so that they can access their file at any place and any time. These services are so convenient to be used. However, it is also well-known that they do not provide much security feature. Anyone holding an URL can access the file concerned even without the need to input any password. 4

5 2. Objectives Our objective is to develop a system which can provide an online storage and sharing platform and, at the same time, with high level of security. The security features include but not limited to: - Secure Transmission Channel The transmission of file and commands between client and server are securely protected using SSH. - Secure Online Storage The files stored in the server are encrypted using TrueCrypt, which is free open-source disk encryption software. - File Integrity Control Integrity check is performed whenever the file is uploaded and downloaded. - Access Control Only authorized user can have access to the file. The developed product is targeting on Small-Medium Enterprise, Organizations and individual users. 5

6 3. System Design 3.1 Security Features This section discuss the features that we have applied to make AirCrypt secure. - Multiple Factor Authentication In AirCrypt, users have to provide their mobile phone s International Mobile Station Equipment Identity (IMEI) and a NFC tag ID during registration. These two tokens will act as the password for authentication. The advantage is users can make use of a longer password without remembering it. Besides, since the two tokens are stored in different mediums, it will be more difficult to be stolen at the same time. - Public/Private Disk Separation Each user, after he/she successfully registered, will be assigned with 2 disks, which is public and private. These 2 disks are both located in the server and encrypted by TrueCrypt. The public disk contains files that file owner shared to others. The cryptography key is stored by the server. When authorized users request the file in the public disk, server will decrypt the disk and perform action on it. The private disk contains files that can only be accessed by the file owner and the cryptography key is kept by the owner. The server will have no knowledge about key. Whenever user wants to perform action on the private drive, he/she needs to send the key to the server. After server finished the action, it would destroy the key immediately. By applying different key management policy on public/private disk, we can provide a maximum privacy and security to the user. - Minimum Exposure Another important design for enhancing the security is by minimizing the exposure time. Exposure time means the time that public/private disks are not encrypted and the time that user can directly interact with the disks. We applied 2 mechanisms to minimize the exposure time. (1) Separation of file information and file data In our design, we store the file information in a separate database. For example, when user opens a folder, the server will send the directory list to the client. The list contains the information of files in this folder. So server will get the information from the database. In this process, the public/private disks remain 6

7 encrypted so file data are protected. (2) Indirect Contact with Encrypted Disks Every actions performed on the file is done in a temporary location. One example is downloading a file. When user wants to download a file, the server will first create a temporary space. Then it will decrypt the disk, copy the file and paste to the temporary space, and encrypt the disk. Then the download will start from the temporary location. So actually user has no direct contact with the disks. The private/public disks in server are encrypted in most of the time and will only be decrypted on demand. By doing so, we hope that it can reduce the possibility of any potential attacks. - SSH Communication Channel The server program and client program communicate through a SSH (Secure Shell) channel. The SSH protocol is the IETF (The Internet Engineering Task Force) standard for secure terminal access. It uses public-key cryptography to authenticate the remote computer. We also make use of SFTP (SSH File Transfer Protocol) for the file transmission. - Integrity check Whenever there is file transmission, we will do file integrity check using the md5 checksum. 7

8 3.2 Other Features - Firewall-Friendly Since we are using SSH as the communication channel. The server only needs to listen to port 22. It avoids complicated setting on the server. - Cross-Platform The AirCrypt Client Program is developed by Java, which means platform independent. The advantage is easy to maintain. Update can be done only once and the executable can run on platforms with java installed. Another advantage is the UI looks similar so user can easily pick up when they switch to different working platform. Windows ubuntu 8

9 3.3 System Architecture The following diagram shows the system architecture. AirCrypt applied the 3-Tier Client/Server Architecture. The Android App obtains the mobile phone s IMEI and NFC tag ID and sends to PC client through Bluetooth. The client and server communicate with each other through the SSH channel. Inside the server, there are program to handle requests from client, several databases which store user s information, file information, etc... and also the public/private disks which are encrypted by TrueCrypt. Components Android App Client Program Server Program DBs Frameworks and Technologies Android SDK 4.2, Java JavaSE-1.7, Bluecove, Standard Widget Toolkit JavaSE-1.7, mysql connector/j, Truecrypt Mysql Public/Private Disks Truecrypt 7.0a SSH Channel Provided by Jsch Library 9

10 3.4 Main Application Flow Registration: Step 1: Step 2: Step 3: Step 4: Step 5: PC client program requests IMEI and NFC tag ID from the android app Android app returns the IMEI and a scanned tag ID PC client sends the username, IMEI and tag ID to the server for registration. Server register the new user, create the public/private disk for the user. If success, return a confirm message. If fail, return an error message. Login: Step 1: Step 2: Step 3: Step 4: Step 5: Step 6: PC client program requests IMEI and NFC tag ID from the android app Android app returns the IMEI and a scanned tag ID PC client sends the username, IMEI and tag ID to the server to authenticate Server authenticate the user If success, server returns a Login Credit to user. The Login Credit consists of the Unix login name and password. If fails, server returns an error message. PC client login to the server again using the Login Credit. 10

11 Upload (default private): Step 1: Step 2: Step 3: Step 4: Step 5: Step 6: PC client program sends the file to server Server checks the file integrity If success, server request user to provide private key because, by default, newly uploaded file will be put in the private disk. If fail, server returns error message. Client sends the private key Server unlocks the private disk and copy the file to the disk. After that, server will immediately encrypt the disk and destroy the key. If success, server returns a confirm message. If fail, server returns an error message. Download (private): Step 1: Step 2: Step 3: PC client program sends the request of the file and the private key Server uses the key to decrypt the private disk, copy the file to a temporary location. After that, server will immediately encrypt the disk and destroy the key. If success, server will transfer the file from temporary location to user. If fail, server returns error message. 11

12 Download (public): Step 1: Step 2: Step 3: PC client program sends the request of the file. Server checks the access right of the file. If user has the right, server will get the key from database and use the key to decrypt the public disk, copy the file to a temporary location. Then public disk will then be encrypted again. If success, server will transfer the file from temporary location to user. If fail, server returns error message. Access Control: Step 1: Step 2: Step 3: Step 4: Step 5: Step 6: User wants to change the access right of a file. Client program requests the list of access right of the file. The list contains users who are permitted to access the file. Server returns the list. User modifies the list through client program. Client program sends the modified list back to server. Server changes the access right according to the modified list. If success, server returns confirm message. If fail, server returns error message. 12

13 4. Current Progress 4.1 Android App At this stage, we have successfully developed the android app. The android app is able to scan the NFC tag and get the tag ID. Then it will send the tag ID with the phone s IMEI to the PC Client Program through Bluetooth. 13

14 4.2 Server and Client Program Most of the functions like upload, download and access control are already implemented. However, at this stage, we have only tested the login function and combined the GUI with it. The following screenshots show the testing of login function. Register User: demo Correct IMEI: 353xxxxxxxx Correct tag ID: 0x3b4644b6 Screenshot 1: Unregistered user login Screenshot 2: Registered user login with correct IMEI and NFC tag ID 14

15 Screenshot 3: Registered user login with wrong IMEI but correct NFC tag ID Screenshot 4: Registered user login with correct IMEI but wrong NFC tag ID 15

16 5. Development Tools (A) Eclipse [4.2.1] Eclipse SDK is free and open source software. It is popular software to develop applications in Java. It also provides useful libraries like JFace which helps our project to develop the GUI of the client program. (B) Android SDK [4.2] The Android SDK provides the API libraries and developer tools necessary to build, test, and debug apps for Android. It also contains sample codes about NFC functions which help a lot in developing our Android App. (C) ubuntu [12.04 LTS] We use ubuntu as our server s OS. ubuntu is a Unix-based Operating System. It has fast update of security batch. Also it is more secure when comparing with Windows. 16

17 6. Limitations and Difficulties Encountered 6.1 Limitations - Authentication Tokens Since we use IMEI and NFC tag ID as the authentication token, user must have a mobile phone with NFC function supported. At this moment, only a few android devices support the NFC function. - Bluetooth The Android App communicates with the PC client program through Bluetooth. Therefore, user s PC has to be equipped with Bluetooth. 6.2 Difficulties Encountered and Our Solutions - Permission problem We need to care about the folder/file permission to let authorized user to access the file to achieve the minimum privilege principle. For example: we make the private mount point as (drwx------,i.e. 700), set the owner and the group as the account holder (USER1:Account) to prevent unauthorized user to get into the mountpoint. Another example: we make the sharing mount point as (drwxr-x---,i.e. 750), set the owner and the group as the account holder (USER1:Account) to enable user to access to the mountpoint and get the file. - Account setup It is not feasible to create an UNIX account when a registration is done because of the security issue. So we are going to make the accounts REGULARLY using crontab utility (also called cron-job), schedule account creation each day. - SSH setting We need to decline the access of root accounts so that the hacker cannot take control using root accounts via SSH. (In Ubuntu LTS, after installing ssh package, edit it by sudo nano /etc/ssh/sshd_config And change the option PermitRootLogin Yes PermitRootLogin No) 17

18 - Truecrypt As well known, mounting need root permission. To prevent exposing password of root account when mounting, we need to add Truecrypt application as one application that execute as root permission without password. We use visudo utility to achieve this. - Java environment setting Since Ubuntu LTS does not have Java 7 included in the package (not available to Ubuntu default repository), we need to manually add a Java repository to install JRE and JDK. OpenJDK is not compatible to this program. - NFC detection The mobile device may already install Apps which can automatically detect the NFC tag. According to the Android SDK, a NFC signal can only be handled by one application. Therefore, in order to avoid the interruption by other Apps, we use enableforegrounddispatch to dominate the NFC detection when our App is opened. Another problem of NFC detection is the data obtained from the tag. The data retrieved from the tag is an array of byte. Therefore, we have to write our own function to convert the bytes into meaningful string. 18

19 7. Work Division Fong Chun Sing Leung Sui Lun Client Side - Program - Android App Server Side - Program - Set-up - configuration System Design Presentation Report 19

20 8. Future Plan - Sharing Function In our initial design, the user shares the file by assigning the access right and sends a link to another user for download. However, we think it may not be convenient for user. So we are considering implementing an exchanging system. When user A assigns the access right to user B, the server will automatically send a message to notify user B about the permission. - Prevent request replay attack In this stage, we don t add the mechanism on preventing replay attack because we want to develop and debug easily. In fact, preventing replay attack is important for any system to prevent potential attack. We will achieve that by adding a random generated temporary token to the request to prevent replay attack. - Encrypt all request In this stage, request are sent with plain text (although the transmission channel is secure), it is safe to encrypt the request with symmetric key to prevent any potential misuse of system. - Change password lifetime of an UNIX account At this stage, all UNIX password and username are stored in database permanently and we are not going to modify that password. In fact, it is better to change the password lifetime to prevent potential attack. We will adopt the method on how an account is created. We create a cronjob that regularly update the password of the UNIX account. 20