Bài giảng Database systems - 8. Functional dependencies & normalization

DATABASE SYSTEMS Nguyen Ngoc Thien An FUNCTIONAL DEPENDENCIES & NORMALIZATION Spring 2014 Contents 2  Introduction to Database Security  Discretionary Access Control (DAC)  Mandatory Access Control (MAC)  Role-Based Access Control (RBAC)  Encryption & Public Key Infrastructure (PKI)  Common Attacks on Databases  SQL Injection  Challenges of Database Security Reading Suggestion: [1] Chapter 24 Contents 3  Introduction to Database Security  Database Security Issues  Threats to Databases  Countermeasures  Database Security Mechanisms  Database Security and the DBA  Access Protection, User Accounts, and Database Audits  Sensitive Data Database Security Issues 4  Legal and ethical issues: privacy issues.  Policy issues: what a government or corporate entity allows or disallows.  System-related issues: handle a security issue at hardware, OS, DBMS level.  The need to identify multiple security levels: identify security levels and categorize the data and users based on these classifications (e.g.: top secret, secret, confidential, and unclassified). Threats to Databases 5  Threats: Any situation or event, whether intentional or unintentional, that will adversely affect a system and consequently an organization.  Threats to:  Computer systems.  Databases.  Threats to databases:  Loss of integrity.  Loss of availability.  Loss of confidentiality. 6 Threats to Computer Systems 7 Scope of Data Security Needs •Must protect databases & the servers on which they reside •Must administer & protect the rights of internal database users •Must guarantee the confidentiality of ecommerce customers as they access the database •With the Internet continually growing, the threat to data traveling over the network increases exponentially Contents 8  Introduction to Database Security  Database Security Issues  Threats to Databases  Countermeasures  Database Security Mechanisms  Database Security and the DBA  Access Protection, User Accounts, and Database Audits  Sensitive Data Countermeasures (1) 9  To protect databases against these types of threats, four main kinds of countermeasures (control measures) can be implemented:  Access control.  Inference control.  Flow control.  Data encryption. Countermeasures (2) 10  Access Control  The security mechanism of a DBMS which must include provisions for restricting access to the database as a whole.  Authentication: a mechanism that determines whether a user is who he or she claims to be.  Authorization: granting a right or privilege, which enables a subject to legitimately have access to a system or a system’s objects.  Access control is handled by creating user accounts and passwords to control login process by the DBMS. Countermeasures (3) 11  Inference Control  The countermeasures to statistical database security problem.  Statistical databases: used to provide statistical information or summaries of values based on various criteria.  Statistical database security must ensure:  Information about individuals cannot be accessed.  Cannot deduce or infer certain facts concerning individuals from queries that involve only summary statistics on groups. Countermeasures (4) 12  Flow control  Prevent information from flowing in such a way that it reaches unauthorized users.  Covert channels: channels that are pathways for information to flow implicitly in ways that violate the security policy of an organization. Countermeasures (5) 13  Data encryption  Protect sensitive data (e.g.: credit card numbers) that is being transmitted via some type communication network.  The data is encoded using some encoding algorithm.  An unauthorized user who access encoded data will have difficulty deciphering it, but authorized users are given decoding or decrypting algorithms (or keys) to decipher data. Contents 14  Introduction to Database Security  Database Security Issues  Threats to Databases  Countermeasures  Database Security Mechanisms  Database Security and the DBA  Access Protection, User Accounts, and Database Audits  Sensitive Data Database Security Mechanisms 15  A DBMS typically includes a database security and authorization subsystem that is responsible for ensuring the security portions of a database against unauthorized access.  Two types of database security mechanisms:  Discretionary security mechanisms.  Mandatory security mechanisms: users at certain classifications can access certain data. Database Security and the DBA (1) 16  The database administrator (DBA) is the central authority for managing a database system.  The DBA’s responsibilities include: Granting privileges to users who need to use the system.  Classifying users and data in accordance with the policy of the organization.  The DBA is responsible for the overall security of the database system. Database Security and the DBA (2) 17  The DBA has a DBA account in the DBMS.  Also called a system or superuser account.  These accounts provide powerful capabilities such as: 1. Account creation. 2. Privilege granting. 3. Privilege revocation. 4. Security level assignment.  Action 1 is access control, whereas 2 and 3 are discretionary and 4 is used to control mandatory authorization. Access Protection, User Accounts, and Database Audits (1) 18  Whenever a person or a group of persons needs to access a database system, the individual or group must first apply for a user account.  The DBA will then create a new account id and password for the user if if there is a legitimate need to access the database.  The user must log in to the DBMS by entering account id and password whenever database access is needed. Access Protection, User Accounts, and Database Audits (2) 19  The database system must also keep track of all operations on the database that are applied by a certain user throughout each login session.  Modify system log to keep a record of all updates applied to the database and of the particular user who applied each update.  System log includes an entry for each operation applied to the database that may be required for recovery from a transaction failure or system crash. Access Protection, User Accounts, and Database Audits (3) 20  If any tampering with the database is suspected, a database audit is performed.  A database audit consists of reviewing the log to examine all accesses and operations applied to the database during a certain time period.  A database log that is used mainly for security purposes is sometimes called an audit trail. Sensitive Data (1) 21  Sensitivity of data is a measure of the importance assigned to the data by its owner for the purpose of denoting its need for protection.  Factors making data sensitive:  Inherently sensitive.  From a sensitive source.  Declared sensitive.  A sensitive attribute or sensitive record.  Sensitive in relation to previously disclosed data. Sensitive Data (2) 22  Information Security vs. Information Privacy:  Information Security: refer to many aspects of protecting a system from unauthorized use, including authentication of users, information encryption, access control, firewall policies, and intrusion detection.  Information Privacy: the ability of individuals to control the terms under which their personal information is acquired and used.  Privacy Issues and Privacy Preservation. Contents 23  Introduction to Database Security  Discretionary Access Control (DAC)  Mandatory Access Control (MAC)  Role-Based Access Control (RBAC)  Encryption & Public Key Infrastructure (PKI)  Common Attacks on Databases  SQL Injection  Challenges of Database Security Contents 24  Discretionary Access Control  Account Level Privileges  Relation Level Privileges  Use Views  Propagation of Privileges  Trojan Horse Example DAC 25  Discretionary Access Control (DAC)  The typical method of enforcing discretionary access control in a database system is based on the granting and revoking privileges.  User can protect what they own.  Owners, DBA or selected users may grant access to others.  Owners, DBA or selected users can define the types of access (read/write/execute/) given to others.  In SQL:  Use GRANT statement for granting privileges.  Use REVOKE statement for revoking privileges. DAC - Types of Privileges 26  Types of discretionary privileges:  The account level (or system level)  At this level, the DBA specifies the particular privileges that each account holds independently of the relations in the database.  The relation level (or table level)  At this level, the DBA can control the privilege to access each individual relation or view in the database. DAC - Account Level 27  The privileges at the account level apply to the capabilities provided to the account itself.  E.g.:  The CREATE SCHEMA or CREATE TABLE privilege, to create a schema or base relation.  The CREATE VIEW privilege.  The ALTER privilege, to apply schema changes such adding or removing attributes from relations.  The DROP privilege, to delete relations or views.  The MODIFY privilege, to insert, delete, or update tuples.  The SELECT privilege, to retrieve information from the database by using a SELECT query. DAC - Relation Level (1) 28  Privileges at the relation level specify for each user the individual relations on which each type of command can be applied.  Some privileges also refer to individual columns (attributes) of relations.  Access Matrix Model: an authorization model for discretionary privileges.  The rows of a matrix M represent subjects (users, accounts, programs).  The columns represent objects (relations, records, columns, views, operations).  Each position M(i,j) in the matrix represents the types of privileges (read, write, update,) that subject i holds on object j. DAC - Relation Level (2) 29 O1 Oi Om S1 A[s1,o1] A[s1,oi] A[s1,om] Si A[si,o1] A[si,oi] A[si,om] Sn A[sn,o1] A[sn,oi] A[sn,om] DAC - Relation Level (3) 30  To control the granting and revoking of relation privileges, for each relation R in a database:  Its owner is given all privileges on that relation.  The owner account holder can pass privileges on any of the owned relation to other users by granting privileges to their accounts.  The owner account holder can also take back the privileges by revoking privileges from their accounts. DAC - Relation Level (4) 31  Types of privileges can be granted on each relation R:  SELECT (retrieval or read) privilege:  Give the retrieval privilege to the account .  The SELECT statement is used to retrieve tuples from R.  MODIFY privileges on R:  Give the account the capability to modify tuples of R.  Divided into UPDATE, DELETE, and INSERT privileges to apply the corresponding SQL command to R.  INSERT and UPDATE privileges can be granted on only certain attributes. DAC - Relation Level (5) 32  Types of privileges can be granted on each relation R (cont.):  REFERENCES privilege on R: Give the account the capability to reference relation R when specifying integrity constraints.  The privilege can also be restricted to specific attributes.  Notice: to create a view, the account must have SELECT privilege on all relations involved in the view definition. Contents 33  Discretionary Access Control  Account Level Privileges  Relation Level Privileges  Use Views  Propagation of Privileges  Trojan Horse Example DAC - Use Views 34  Specifying privileges through the use of views is an important discretionary authorization mechanism in its own right.  E.g.:  If the owner A of a relation R wants another account B to be able to retrieve only some fields of R,then A can create a view V of R that includes only those attributes and then grant SELECT on V to B.  The same applies to limiting B to retrieving only certain tuples of R. A view V’ can be created by defining the view by means of a query that selects only those tuples from R that A wants to allow B to access. Contents 35  Discretionary Access Control  Account Level Privileges  Relation Level Privileges  Use Views  Propagation of Privileges  Trojan Horse Example DAC - Propagation of Privileges (1) 36  Propagation of account level privileges:  Whenever an authorized user A grants an account level privilege to a user B, this privilege can be given to B with or without the ADMIN OPTION.  If the ADMIN OPTION is given, this means that B can also grant that privilege to other accounts with or without ADMIN OPTION. User A does not know about the propagation of that privilege to other users.  If the privilege is revoked from B, then accounts who have received that privilege from B still hold that privilge. DAC - Propagation of Privileges (2) 37  Propagation of relation level privileges:  Whenever an authorized user A grants a privilege on a relation R to a user B, this privilege can be given to B with or without the GRANT OPTION.  If the GRANT OPTION is given, this means that B can also grant that privilege on R to other accounts with or without GRANT OPTION. User A does not know about the propagation of that privilege on R to other users.  If the privilege on R is revoked from B, then that privilege on R is also revoked automatically from accounts who have received it from B. DAC - Propagation of Privileges (3) 38 DAC - Propagation of Privileges (4) 39  Techniques to limit the propagation of privileges have been developed, although they have not yet been implemented in most DBMSs and are not a part of SQL.  Limiting horizontal propagation to an integer number i means that an account B given the GRANT OPTION can grant the privilege to at most i other accounts.  Limiting vertical propagation is more complicated. It limits the depth of the granting of privileges. DAC - Propagation of Privileges (5) 40 Limit horizontal propagation DAC - Propagation of Privileges (6) 41 Limit vertical propagation DAC - An Example (1) 42  Suppose that the DBA creates 4 accounts: A1, A2, A3, A4.  For only A1 to be able to create base relations, DBA must issue the following GRANT command in SQL: GRANT CREATETAB TO A1;  DBA creates schema EXAMPLE and grants privileges on it to A1: CREATE SCHEMA EXAMPLE AUTHORIZATION A1; DAC - An Example (2) 43  A1 can create tables under the schema EXAMPLE.  A1 creates the 2 relations EMPLOYEE and DEPARTMENT so that A1 is the owner of these relations and hence have all the relation privileges on each of them. DAC - An Example (3) 44  A1 wants to grant A2 the privilegea to insert and delete tuples in both of these relations but does not want A2 to be able to propagate these privileges to other accounts: GRANT INSERT, DELETE ON EMPLOYEE, DEPARTMENT TO A2;  A1 wants to allow A3 to retrieve information from either of the two tables and also to be able to propagate the SELECT privilege to other accounts. GRANT SELECT ON EMPLOYEE, DEPARTMENT TO A3 WITH GRANT OPTION; DAC - An Example (4) 45  A3 can grant the SELECT privilege on the EMPLOYEE relation to A4: GRANT SELECT ON EMPLOYEE TO A4;  Notice that A4 cannnot propagate the SELECT privilege because GRANT OPTION was not given to A4. DAC - An Example (5) 46  A1 decides to revoke the SELECT privilege on EMPLOYEE from A3: REVOKE SELECT ON EMPLOYEE FROM A3;  The DBMS must now automatically revoke the SELECT privilege on EMPLOYEE from A4, because A3 granted that privilege to A4 and A3 does not have the privilege any more. DAC - An Example (6) 47  A1 wants to give back A3 a limited capability to SELECT from the EMPLOYEE relation and allow A3 to be able to propagate the privilege.  The limitation is to retrieve only the NAME, BDATE, and ADDRESS attributes and only for the tuples with DNO = 5.  A1 then creates the view: CREATE VIEW A3_EMPLOYEE AS SELECT NAME, BDATE, ADDRESS FROM EMPLOYEE WHERE DNO = 5;  After the view is created, A1 can grant SELECT on the view A3_EMPLOYEE to A3 as follows: GRANT SELECT ON A3_EMPLOYEE TO A3 WITH GRANT OPTION; DAC - An Example (7) 48  A1 wants to allow A4 to update only the SALARY attribute of EMPLOYEE: GRANT UPDATE ON EMPLOYEE (SALARY) TO A4;  The UPDATE and INSERT privileges can specify particular attributes that may be updated or inserted in a relation.  Other privileges (SELECT, DELETE) are not attribute specific. Contents 49  Discretionary Access Control  Account Level Privileges  Relation Level Privileges  Use Views  Propagation of Privileges  Trojan Horse Example DAC 50  Advantages  Govern the access to the information on the basic of discretionary protection policies  flexible.  Suitable for various types of systems and applications.  Be widely used in a variety of implementations, especially in the commercial and industrial environments.  Disadvantages  The main drawback is vulnerability to malicious attacks:  Allow information from an object which can be read by a subject to be written to any other objects.  E.g.: Bob is denied access to file A, so he asks cohort Alice to copy A to B that he can access.  Suppose the users are trusted not to do this deliberately, it is still possible for Trojan Horses to copy information from one object to another. Trojan Horse Example (1) 51 Trojan Horse Example (2) 52 Trojan Horse Example (3) 53 Contents 54  Introduction to Database Security  Discretionary Access Control (DAC)  Mandatory Access Control (MAC)  Role-Based Access Control (RBAC)  Encryption & Public Key Infrastructure (PKI)  Common Attacks on Databases  SQL Injection  Challenges of Database Security Contents 55  Mandatory Access Control  Bell-LaPadula Model  Multilevel Relation  Comparing DAC and MAC MAC - Introduction 56  DAC has traditionally been the main security mechanism for relational database systems.  All-or-nothing method: A user either has or does not have a certain privilege.  Mandatory Access Control (MAC)  Applied to large amounts of information requiring strong protect in environments where both the system data and users can be classified clearly.  A mechanism for enforcing multiple level of security: classify data and users based on security classes.  It would typically be combined with the DAC. MAC - Bell-LaPadula Model 57  Bell-LaPadula Model  Common multilevel security model.  Classify each subject (user, account, program) and object (relation, tuple, column, view, operation) into one security classification.  Class(S): clearance (classification) of a subject S.  Reflect the user’s degree of trust.  Class(O): classification of an object O.  Reflect the sensitivity of the information.  Grant access to data based on subject clearance and object classification.  Principles: no read-up & no write-down secrecy. MAC - Classification Levels 58  Typical classification levels are:  Top secret (TS)  Secret (S)  Confidential (C)  Unclassified (U) Where TS is the highest level and U is the lowest: TS ≥ S ≥ C ≥ U MAC - Properties 59  Simple security property (ss-property): A subject S is not allowed to read an object O unless class(S) ≥ class(O)  No read-up  Star property (or * property): A subject S is not allowed to write an object O unless class(S) ≤ class(O)  No write-down  These restrictions together ensure that there is no direct flow of information from high secure objects to low ones!!! MAC - Why Star Property? (1) 60 MAC - Why Star Property? (2) 61 MAC - Why Star Property? (3) 62 Contents 63  Mandatory Access Control  Bell-LaPadula Model  Multilevel Relation  Comparing DAC and MAC MAC - Multilevel Relation (1)  Multilevel relation: MAC + relational database model  Deal with multilevel data.  Data objects: attributes, tuples.  A multilevel relation is represented by a schema: R (A1,C1,A2,C2, , An,Cn,TC)  Each data attribute Ai is associated with a classification attribute Ci .  Each tuple is associated with a tuple classification attribute TC.  TC is equal to the highest of all attribute classification values.  The apparent key of a multilevel relation is the set of attributes that would have formed the primary key in a regular (single-level) relation. 64 MAC - Multilevel Relation (2) 65  Subjects with different classes may retrieve data from a multilevel relation but will see different versions that data. EMPLOYEE S > C > U Name Salary JobPerformance TC Smith U 40000 C Fair S S Brown C 80000 S Good C S MAC - Multilevel Relation (3) 66  A user with security level S EMPLOYEE S > C > U Name Salary JobPerformance TC Smith U 40000 C Fair S S Brown C 80000 S Good C S SELECT * FROM EMPLOYEE Smith U 40000 C Fair S S Brown C 80000 S Good C S MAC - Multilevel Relation (4) 67  A user with security level C EMPLOYEE S > C > U Name Salary JobPerformance TC Smith U 40000 C Fair S S Brown C 80000 S Good C S SELECT * FROM EMPLOYEE Smith U 40000 C Null C C Brown C Null C Good C C MAC - Multilevel Relation (5) 68  A user with security level U EMPLOYEE S > C > U Name Salary JobPerformance TC Smith U 40000 C Fair S S Brown C 80000 S Good C S SELECT * FROM EMPLOYEE Smith U Null U Null U U MAC - Multilevel Relation (6)  A multilevel relation appears to contain different data to subjects with different clearance levels.  It may store a single tuple at a higher classification level and produce the corresponding tuples at lower-level classifications through a process known as filtering.  Sometimes it must store two or more tuples at different classification levels with the same apparent key value. 69 MAC - Multilevel Relation (7) 70  Integrity rules for multilevel relation:  Entity integrity.  Null integrity and interinstance integrity.  Polyinstantiation. MAC - Multilevel Relation (8) 71  Entity integrity  All attributes that are members of the apparent key:  Must not be null.  And must have the same security classification within each individual tuple.  All the other attribute values in the tuple:  Must have a security classification greater than or equal to that of the apparent key.  This constraint ensures that a user can see the key if the user is permitted to see any part of the tuple at all. MAC - Multilevel Relation (9) 72  Null integrity and interinstance integrity  Ensure that if a tuple value at some security level can be filtered (derived) from a higher-classified tuple, then it is sufficient to store the higher- classified tuple in the multilevel relation.  Polyinstantiation  Where several tuples can have the same apparent key value but have different attribute values for users at different classification levels. MAC - Multilevel Relation (10) 73  A user with security level C Name Salary JobPerformance TC Smith U 40000 C Fair S S Brown C 80000 S Good C S Smith U 40000 C Null C C Brown C Null C Good C C  A user with security level C tries to update the value of JobPerformance of Smith to ‘Excellent’: UPDATE EMPLOYEE SET JobPerformance = ‘Excellent’ WHERE Name = ‘Smith’; Errors? MAC - Multilevel Relation (11) 74 Name Salary JobPerformance TC Smith U 40000 C Fair S S Smith U 40000 C Excellent C C Brown C 80000 S Good C S Contents 75  Mandatory Access Control  Bell-LaPadula Model  Multilevel Relation  Comparing DAC and MAC DAC vs. MAC 76  Mandatory policies:  Ensure a high protection degree by preventing any illegal flow of information.  Being too rigid  Only applicable in limited environments.  Discretionary policies:  Offer a better trade-off between security and applicability.  Be preferred in many practical situations. Contents 77  Introduction to Database Security  Discretionary Access Control (DAC)  Mandatory Access Control (MAC)  Role-Based Access Control (RBAC)  Encryption & Public Key Infrastructure (PKI)  Common Attacks on Databases  SQL Injection  Challenges of Database Security RBAC (1) 78  Role-Based Access Control (RBAC)  A viable alternative to traditional DAC and MAC.  Emerged rapidly in the 1990s as a proven technology for managing and enforcing security in large-scale enterprisewide systems.  Many DBMSs have allowed the concept of roles, where privileges can be assigned to roles. RBAC (2) 79  Role-Based Access Control (RBAC)  Permissions are associated with roles, and users are assigned to appropriate roles.  Roles can be created using the CREATE ROLE and DESTROY ROLE commands.  The GRANT and REVOKE commands are used to assign and revoke privileges from roles.  Role hierarchy in RBAC is a natural way of organizing roles to reflect the organization’s lines of authority and responsibility. Contents 80  Introduction to Database Security  Discretionary Access Control (DAC)  Mandatory Access Control (MAC)  Role-Based Access Control (RBAC)  Encryption & Public Key Infrastructure (PKI)  Common Attacks on Databases  SQL Injection  Challenges of Database Security Contents 81  Encryption & Public Key Infrastructure (PKI)  Terminology  Classification  DES, AES, RSA  Digital Signatures  Public Key Infrastructure Encryption - Terminology 82  Encryption / Decryption: the process of the making / breaking of “secret codes”.  Cipher: an algorithm for performing encryption or decryption.  Plaintext: a message input needing protecting. It may or may not be intelligible.  Ciphertext: the result of encryption performed on plaintext.  Cryptosystem = encryption + decryption algorithms.  Encryption and decryption processes need keys. Encryption - Classification (1)  Symmetric cryptosystems: 𝐾𝐸 = 𝐾𝐷  Asymmetric cryptosystems: 𝐾𝐸 ≠ 𝐾𝐷 83 Cryptosystem Hello, This content is confidential ................... 01000100.. . À¿¾«§¶   .. Encryption Decryption KE KD Plaintext Ciphertext Encryption - Classification (2) 84  Asymmetric cryptosystems  Also called Public-key cryptosystems.  Use two different keys for (en/de)cryption algorithms.  Public key & Private key.  More secure but expensive in terms of computational costs.  Symmetric cryptosystems  Use the same key for (en/de)cryption algorithms.  Symmetric key = Shared-secret-key.  Faster than encryption and decryption in public-key cryptosystems.  Less security comparing to encryption and decryption in public-key cryptosystems. Encryption - Classification (3)  Symmetric cryptosystems:  Stream ciphers: A5/1, RC4.  Block ciphers: DES, Triple DES, AES.  Asymmetric cryptosystems:  RSA, DSA.  Secret Key Establishment.  Digital Signatures.  Digital Certificate. 85 Contents 86  Encryption & Public Key Infrastructure (PKI)  Terminology  Classification  DES, AES, RSA  Digital Signatures  Public Key Infrastructure Encryption - DES 87  DES (Data Encryption Standard)  Published by the USA’s National Bureau of Standards (NBS).  Be used as the encryption standard for unclassified data (information not concerned with national security).  A message is divided into 64-bit blocks.  Key: 56 bits  Brute-force (exhaustive key search) attack in some hours  Today, it’s too small.  Triple DES: run the DES algorithm a multiple number of times using different keys  Encryption: 𝒄 ← 𝓔𝒌𝟏(𝓓𝒌𝟐(𝓔𝒌𝟏(𝒎)))  Decryption: 𝒎 ← 𝓓𝒌𝟏(𝓔𝒌𝟐(𝓓𝒌𝟏(𝒄)))  The triple DES can also use three different keys. Encryption - AES 88  AES (Advanced Encryption Standard / Rijndael)  Chosen and introduced by the National Institute of Standards and Technology (NIST) (known as NBS before).  Be secure and can be implemented efficiently.  The new encryption standard to replace for DES and multiple encryption (as Triple DES) Reduce the cost of managing keys. Simplify the design of security protocols and systems.  A block cipher with a variable block size and variable key size.  The key size and the block size can be independently specified to 128, 192 or 256 bits  The enlarged and variable key and data-block sizes can accommodate a wide spectrum of security strengths for various application needs. Encryption - RSA 89  RSA (named after 3 inventors Rivest, Shamir and Adleman)  Public key is used for encrytion.  Private key is used for decrytion. Encryption - Hybrid Scheme 90  Hybrid scheme  Asymmetric technique: establish a symmetric key.  Symmetric technique: encrypt data by that symmetric key. Sender Receiver Encrypted message using a symmetric key Use public key of receiver to encrypt the message encryption key Contents 91  Encryption & Public Key Infrastructure (PKI)  Terminology  Classification  DES, AES, RSA  Digital Signatures  Public Key Infrastructure Digital Signatures (1) 92  Digital Signature: a message signed with a user's private key and can be verified by anyone who has access to the user's public key.  Thus:  Authentication: Anyone with the user’s public key can verify his digital signature  Easy to verify who is the owner of the message.  Data integrity: The message cannot be modified without being detected during decryption time  Verify whether the message is modified or not.  Non-repudiation: Only the holder of the private key can digitally sign  Prevent the sender from claiming that he did not actually send the information. Digital Signatures (2) 93 Simple Digital Signatures Digital Signatures (3) 94 Secure Digital Signatures Contents 95  Encryption & Public Key Infrastructure (PKI)  Terminology  Classification  DES, AES, RSA  Digital Signatures  Public Key Infrastructure Public Key Infrastructure (1) 96  Public Key Infrastructure (PKI)  The sum total of everything required to securely use public key crypto.  Digital Certificate  Also called Identity Certificate, or Public Key Certificate.  An electronic document which is used to verify that a public key belongs to an individual.  Use a digital signature to bind a public key with an identity.  In most situations the certificate must be signed by a Certificate Authority (CA), which acts as a trusted third party. Public Key Infrastructure (2) 97  Each digital certificate contains basic information:  The owner’s identity: information such as the name of a person or an organization, their address or their server address, and so forth.  The owner’s public key.  The date of issue of the certificate.  Valid time (‘Valid From’ and ‘Valid To’ dates).  Name and URL of the CA.  The digital signature of the issuing CA. CA Public Key Infrastructure (3) 98 Sender S Receiver R Certificate Authority (CA) Encrypted message using a symmetric key Use R’s public key to encrypt the message encryption key 3 - Send data 4 - Receive data & decrypt it TRUSTED How does PKI work? Public Key Infrastructure (4) 99  A digital certificate can be revoked if:  Its private key is compromised.  The relationship of the public key and the owner is changed.  A certificate was issued in error.  Use the Certificate Revocation List.  The largest commercial source for certificates is VeriSign. Contents 100  Introduction to Database Security  Discretionary Access Control (DAC)  Mandatory Access Control (MAC)  Role-Based Access Control (RBAC)  Encryption & Public Key Infrastructure (PKI)  Common Attacks on Databases  SQL Injection  Challenges of Database Security Common Attacks on Databases 101  Some of quite frequent attacks on databases:  Unauthorized Privilege Escalation.  Privilege Abuse.  Denial of Service (DOS attack).  Weak Authentication.  SQL Injection. Contents 102  Introduction to Database Security  Discretionary Access Control (DAC)  Mandatory Access Control (MAC)  Role-Based Access Control (RBAC)  Encryption & Public Key Infrastructure (PKI)  Common Attacks on Databases  SQL Injection  Challenges of Database Security SQL Injection (1) 103  SQL Injection Attack  Web programs and applications that access a database can send commands and data to the database.  The attacker injects a string input through the application, which changes or manipulates the SQL statement to the attacker’s advantage. Most commonly done directly through web forms, but can be directed through URL hacking. SQL Injection (2) 104  SQL Injection  Exploit a security vulnerability in application.  Authentication bypass, information disclosure, compromised data integrity.  Harm the database  Unauthorized manipulation of the database, or retrieval of sensitive data.  Execute system level commands that may cause the system to deny service to the application. SQL Injection (3) 105  Consider an embedded code: $query = “SELECT prodinfo FROM prodtable WHERE prodname = ‘ “$_INPUT(‘prod_search’)” ’ ”  User enters the following: blah’ OR ‘x’ = ‘x’  SQL statement created: SELECT prodinfo FROM prodtable WHERE prodname = ‘blah’ OR ‘x’ = ‘x’; SQL Injection (4) 106  A more serious problem, a user enters: blah'; DROP TABLE prodinfo;  SQL statement created: SELECT prodinfo FROM prodtable WHERE prodname = ‘blah’; DROP TABLE prodtable;  Another example: SELECT * FROM Users WHERE username = ‘John’ and (PASSWORD = ‘JohnPass’ or ‘x’ = ‘x’); Contents 107  Introduction to Database Security  Discretionary Access Control (DAC)  Mandatory Access Control (MAC)  Role-Based Access Control (RBAC)  Encryption & Public Key Infrastructure (PKI)  Common Attacks on Databases  SQL Injection  Challenges of Database Security Challenges of Database Security (1) 108  Data Quality  Need techniques and organizational solutions to assess and attest the quality of data.  Need techniques providing more effective integrity semantics verification.  Need tools for the assessment of data quality.  Intellectual Property Rights  Digital watermarking techniques. Challenges of Database Security (2) 109  Database Survivability: Database systems need to operate and continue their functions, even with reduced capabilities, despite disruptive events such as information warfare attacks.  Confinement.  Damage assessment.  Reconfiguration.  Repair.  Fault treatment. Q & A 110