1. Data security 1

2. 2 Overview  generalities  discretionary access control  mandatory access control  data encryption

3. Data security 3  aspects  origins of security rules  social - legal, ethical, political, strategic,...  operational problems  are the computers “safe”?  does the operating system have a security system (passwords, storage protection keys...)? ...  does the DBMS have a concept of data ownership? The problem of security

4. Data security 4 disregard

5. Data security 5 DBMS approaches to data security  discretionary  users access data according to their privileges / authorities which are explicitly stated for each user and data object in part  mandatory  each data object is given a classification level and each user has a certain clearance level; a given data object can be accessed only by the users with a certain clearance level

6. Data security 6 The DBMS’s security mechanism  security rules:  made known to the system  appropriate definitional language  remembered by the system  security / authorisation rules stored in the catalogue  checked by the system  security / authorisation subsystem

7. Data security 7 Discretionary access control  example in a pseudo-code CREATE SECURITY RULE Rule1 GRANT RETRIEVE ( S_id, S_name, City ), DELETE ON Suppliers WHERE City  ‘London’ TO Jim, Fred, Mary ON ATTEMPTED VIOLATION Reject ;

8. Data security 8 Discretionary access control  components of a security rule  name (Rule1) (why?)  privileges (RETRIEVE on certain attributes,...)  scope (ON … WHERE …)  users (user IDs)  violation response (procedure)

9. Data security 9 General format of a rule (pseudo-code) CREATE SECURITY RULE GRANT ON TO [ ON ATTEMPTED VIOLATION ] ;

10. Data security 10 Clarifications  possible privileges are:  RETRIEVE [ ( ) ]  INSERT  UPDATE [ ( ) ]  DELETE  ALL  data definition operations ...

11. Data security 11 Clarifications   is an expression of relational algebra  target: (one range variable which should refer to) only one relation; i.e. the scope of the rule is a subset of of the tuples of a single relation this restriction is somehow ad-hoc; though, it induces in simplicity   default: reject  but it could be on any complexity, in theory examples - what would it be needed?

12. Data security 12 SQL’s GRANT and REVOKE GRANT ON TO | PUBLIC [ WITH GRANT OPTION ] REVOKE [ GRANT OPTION FOR] ON FROM

13. Data security 13 Clarifications  privileges  USAGE (for domains), SELECT, INSERT (column specific), UPDATE (column specific), DELETE, REFERENCES (for integrity constraint definitions)   DOMAIN  [ TABLE ] (a base table or a view)   RESTRICT | CASCADE

14. Data security 14 Example #1 CREATE VIEW View1 AS SELECT S_id, S_name, Status, City FROM SuppliersWHERE City = ‘Paris’ GRANT SELECT, INSERT, UPDATE ( S_name, Status ), DELETE ON View1 TO Mark, Spencer

15. Data security 15 Example #2 CREATE VIEW View2 AS SELECT S_id, S_name, Status, City FROM SWHERE EXISTS ( SELECT * FROM SP WHERE EXISTS (SELECT * FROM P WHERE S.S_id = SP.S_id AND P.P_id = SP.P_id AND P.City = ‘Rome’ )) ; GRANT SELECT ON View2 TO John

16. Data security 16 CREATE VIEW View3 AS SELECT P_id, ( SELECT SUM (Contracts.Qty) FROM Contracts WHERE Contracts.P_id = Parts.P_id ) AS Quantity FROM Parts; GRANT SELECT ON View3 TO Bill Example #3

17. Data security 17 Other issues  context-independent rules  the previous examples  context-dependent rules  date(), day(), time(), user(), terminal() specified within the rule

18. Data security 18 GRANT INSERT ON Transactions WHERE Day() NOT IN (‘Saturday’, ‘Sunday’) AND Time() > ’ 9:00’ AND Time() < ‘17:00’ TO Till;--Till is a group of users Example #4

19. Data security 19 Other issues  logical “OR” between security rules  anything not explicitly allowed is implicitly prohibited  audit trial - for critical data  request (text), terminal, user, date and time, data objects affected, old values, new values

20. Data security 20 Mandatory access control  each data object has a classification level  each user has a clearance level  rules  user U can see object O if the clearance level of U is greater or equal to the classification level of O  user U can modify object O only if the clearance level of U is equal to the classification level of O  used for DBs with a static and rigid classification structure

21. Data security 21 Data encryption - generalities  when the system was bypassed  plain-text  original data  encryption  encryption algorithm, encryption key  cipher-text  encrypted text

22. Data security 22 An encryption algorithm  divide text into blocks of length equal to the encryption key  replace each character by a corresponding integer (blank=00, a=01, …, z=26)  repeat for the encryption key  for each block, sum modulo 27 the corresponding integers with those of the encryption key  replace each integer with the corresponding character

23. Data security 23 Example  plaintext: we all like databases  key: ursu  [we_a][ll-l][ike-][data][base][s---]  23050001 12120012 09110500 04012001 02011905 19000000  21181921  17231922 06031906 … --exercise  qwsv fcsf …  decoding algorithm?

24. Data security 24 Objective  the cost of breaking the coding algorithm should be greater than the potential payoff of accessing (illegally) the encoded data  usually, the encryption algorithm is made public but the encryption key is kept secret  the breaking of the coding (find the encryption key), usually, is done on the bases of some available cipher-texts and their corresponding plain-texts

25. Data security 25 Encryption algorithms  data encryption standard  not truly secure  public-key encryption  a modern approach

26. Data security 26 Data encryption standard  64 bit key (actually only 2 56 possible keys)  permutation + 16 substitution steps + permutation  each substitution step is based on a new key that is computed from the current value of the block and the initial value of the key  the decryption algorithm is almost identical to the encryption one

27. Data security 27 Public-key encryption makes public - encryption algorithm - encryption key keeps - decryption key

28. Data security 28 Principles for public key encryption  the decryption key cannot feasibly be deduced from the encryption key  there is a fast algorithm of determining whether a given number is prime  e.g. for a no of 130 digits - 7 minutes  there is no fast algorithm for finding the factors of a given non-prime number  e.g. for a product of two prime no of 63 digits - 4 * 10 16 years

29. Data security 29 “Signed” public key encryption publishes encryption algorithm E1 and encryption key corresponding decryption algorithm (key) D1 is kept secret publishes encryption algorithm E2 and encryption key corresponding decryption algorithm (key) D2 is kept secret E2(D1(Original)) E1(D2(Received)) = E1(D2(E2(D1(Original)))) = E1(D1(Original)= Original

30. Data security 30 Conclusions  decisions on security issues  dictated by policy  various aspects to the security problem  database security mechanisms  discretionary  mandatory  data encryption  for cases when the security system was bypassed