mobile-security.pptx (Size: 1.35 MB / Downloads: 259)
NEED FOR MOBILE DATABASE
• Mobile users must be able to work without a wireless connection due to poor or even non-existent connections.
• Applications must be able to access local device/vehicle hardware, such as printers, bar code scanners, or GPS units (for mapping or Automatic Vehicle Location systems).
• Bandwidth must be conserved (a common requirement on wireless networks that charge per megabyte or data transferred).
• Location Dependent Data (LDD):- The class of data whose value is functionally dependent on location. Thus the value of location determines the correct value of data. Ex- City tax, City area.
How m. d. s look at database data
• Location Independent Data (LID):- The class of data whose value is functionally independent on location. Thus the value of location does not determines the correct value of data. Ex- Person name , account nuber.
1. Secure network connection
• The mobile database and the central database have to be synchronized at specific times. We have selected the secure http protocol (https) to perform the necessary synchronization operations between the mobile and the central database. More precisely we use https with server and client authentication. This choice assures:
– Confidentiality of the data that is transferred.
– Authentication of the server computer.
– Authentication of the client computer.
2. Encrypted local database
The local database on the mobile device is encrypted and each time the user opens the mobile database, he has to enter his password. In case the mobile device is stolen or violated by an intruder, the data that is stored on the local database is not readable. The encryption algorithm is part of SQL Server Mobile Edition and unfortunately we were not able to find documentation for the specific algorithm.
3. Application provided security
For authoring operations, each user has access only to his own data. A set of database triggers implemented in the database server, check that the data manipulation operations of the user are valid. This check prevents all users from accidental or malicious modifications of data for which they have no authorization. More precisely, an author
– can create new announcements that are signed with his name,
– can delete or update announcements that are signed with his name, and
– has no access to announcements created/signed by other users.