21. Terminology &
definitions
• Cryptographers and computer security
people talk a different language (e.g.
‘authentication’ vs ‘authorisation’)
• Integrity(Data authentication? Entity authentication?)
• Availability (Denial of Service? Non-repudiation?)
• Confidentiality
• Trust
22. Terminology &
definitions
• Cryptographers and computer security
people talk a different language (e.g.
‘authentication’ vs ‘authorisation’)
• Integrity(Data authentication? Entity authentication?)
• Availability (Denial of Service? Non-repudiation?)
• Confidentiality
• Trust
23. Terminology &
definitions
• Cryptographers and computer security
people talk a different language (e.g.
‘authentication’ vs ‘authorisation’)
• Integrity(Data authentication? Entity authentication?)
• Availability (Denial of Service? Non-repudiation?)
• Confidentiality
• Trust
24. Terminology &
definitions
• Cryptographers and computer security
people talk a different language (e.g.
‘authentication’ vs ‘authorisation’)
• Integrity(Data authentication? Entity authentication?)
• Availability (Denial of Service? Non-repudiation?)
• Confidentiality
• Trust
25. Terminology &
definitions
• Cryptographers and computer security
people talk a different language (e.g.
‘authentication’ vs ‘authorisation’)
• Integrity(Data authentication? Entity authentication?)
• Availability (Denial of Service? Non-repudiation?)
• Confidentiality
• Trust
26. Vertrouwen (trust)
➡ Dieter Gollman:
“Trust is not the ➡ Based on
concept that ➡ reputation
unifies security, it ➡ control and
is an absolute punishment
mess.”
➡ policy enforcement
➡ “If it is trusted, it ➡ ... or blind
can hurt you.”
27. Vertrouwen (trust)
➡ Dieter Gollman:
“Trust is not the ➡ Based on
concept that ➡ reputation
unifies security, it ➡ control and
is an absolute punishment
mess.”
➡ policy enforcement
➡ “If it is trusted, it ➡ ... or blind
can hurt you.”
28. Vertrouwen (trust)
➡ Dieter Gollman:
“Trust is not the ➡ Based on
concept that ➡ reputation
unifies security, it ➡ control and
is an absolute punishment
mess.”
➡ policy enforcement
➡ “If it is trusted, it ➡ ... or blind
can hurt you.”
40. Don’ts
• Security and complexity do not mix:
• operating system
• network architecture
• applications
• mobile code
• services: XML, SOAP, VoIP (through the firewall!)
• always on connections (botnets!)
41. Don’ts
• Security and complexity do not mix:
• operating system
• network architecture
• applications
• mobile code
• services: XML, SOAP, VoIP (through the firewall!)
• always on connections (botnets!)
42. Don’ts
• Security and complexity do not mix:
• operating system
• network architecture
• applications
• mobile code
• services: XML, SOAP, VoIP (through the firewall!)
• always on connections (botnets!)
43. Don’ts
• Security and complexity do not mix:
• operating system
• network architecture
• applications
• mobile code
• services: XML, SOAP, VoIP (through the firewall!)
• always on connections (botnets!)
44. Don’ts
• Security and complexity do not mix:
• operating system
• network architecture
• applications
• mobile code
• services: XML, SOAP, VoIP (through the firewall!)
• always on connections (botnets!)
45. Don’ts
• Security and complexity do not mix:
• operating system
• network architecture
• applications
• mobile code
• services: XML, SOAP, VoIP (through the firewall!)
• always on connections (botnets!)
46. Don’ts
• Security through obscurity:
• mobile phone systems: GSM in US
• DVD copyright protection (DVD Jon!)
• Sony rootkit
• Diebold voting machines
• Microsoft
• Cisco router OS
• physical locks
• blacking out text in PDF (hack: “read out loud”)
47. Don’ts
• Security through obscurity:
• mobile phone systems: GSM in US
• DVD copyright protection (DVD Jon!)
• Sony rootkit
• Diebold voting machines
• Microsoft
• Cisco router OS
• physical locks
• blacking out text in PDF (hack: “read out loud”)
48. Don’ts
• Security through obscurity:
• mobile phone systems: GSM in US
• DVD copyright protection (DVD Jon!)
• Sony rootkit
• Diebold voting machines
• Microsoft
• Cisco router OS
• physical locks
• blacking out text in PDF (hack: “read out loud”)
49. Don’ts
• Security through obscurity:
• mobile phone systems: GSM in US
• DVD copyright protection (DVD Jon!)
• Sony rootkit
• Diebold voting machines
• Microsoft
• Cisco router OS
• physical locks
• blacking out text in PDF (hack: “read out loud”)
50. Don’ts
• Security through obscurity:
• mobile phone systems: GSM in US
• DVD copyright protection (DVD Jon!)
• Sony rootkit
• Diebold voting machines
• Microsoft
• Cisco router OS
• physical locks
• blacking out text in PDF (hack: “read out loud”)
51. Don’ts
• Security through obscurity:
• mobile phone systems: GSM in US
• DVD copyright protection (DVD Jon!)
• Sony rootkit
• Diebold voting machines
• Microsoft
• Cisco router OS
• physical locks
• blacking out text in PDF (hack: “read out loud”)
52. Don’ts
• Security through obscurity:
• mobile phone systems: GSM in US
• DVD copyright protection (DVD Jon!)
• Sony rootkit
• Diebold voting machines
• Microsoft
• Cisco router OS
• physical locks
• blacking out text in PDF (hack: “read out loud”)
53. Don’ts
• Security through obscurity:
• mobile phone systems: GSM in US
• DVD copyright protection (DVD Jon!)
• Sony rootkit
• Diebold voting machines
• Microsoft
• Cisco router OS
• physical locks
• blacking out text in PDF (hack: “read out loud”)
54. Don’ts
• Risk avoidance:
• accept the risk
• reduce risk with technology
• reduce risk with procedures
• reduce risk with insurance
• reduce risk with disclaimers
• transfer the risk (e.g.: from data to key)
55. Don’ts
• Risk avoidance:
• accept the risk
• reduce risk with technology
• reduce risk with procedures
• reduce risk with insurance
• reduce risk with disclaimers
• transfer the risk (e.g.: from data to key)
56. Don’ts
• Risk avoidance:
• accept the risk
• reduce risk with technology
• reduce risk with procedures
• reduce risk with insurance
• reduce risk with disclaimers
• transfer the risk (e.g.: from data to key)
57. Don’ts
• Risk avoidance:
• accept the risk
• reduce risk with technology
• reduce risk with procedures
• reduce risk with insurance
• reduce risk with disclaimers
• transfer the risk (e.g.: from data to key)
58. Don’ts
• Risk avoidance:
• accept the risk
• reduce risk with technology
• reduce risk with procedures
• reduce risk with insurance
• reduce risk with disclaimers
• transfer the risk (e.g.: from data to key)
59. Don’ts
• Risk avoidance:
• accept the risk
• reduce risk with technology
• reduce risk with procedures
• reduce risk with insurance
• reduce risk with disclaimers
• transfer the risk (e.g.: from data to key)
60. Don’ts
• Security is not forever:
• Cryptography:
• 1958 vs now : peanuts
• now vs 2058 : ?
• Advances in:
• reverse engineering
• side channel attacks
61. Don’ts
• Security is not forever:
• Cryptography:
• 1958 vs now : peanuts
• now vs 2058 : ?
• Advances in:
• reverse engineering
• side channel attacks
62. Don’ts
• Security and complexity don’t mix
• Security through obscurity does not work
• 100% security doesn’t exist
• Security is not forever
79. Do’s
• Clearly state the assumptions behind the system.
• Need for integrated approach
• Find the right mix of technology and law
• Need for secure implementations
80. Secure implementations
• “Nothing is more practical than a good
theory”
• “Theory is important, at least in theory”
81. Secure implementations
• Consider:
• Secure software/hardware (orlly?)
• Side channel attacks
• Buffer overflows
• API errors
• Random number generators
• Model vs reality
96. Credits
• Introduction to security and course overview,
prof. dr. ir. Bart Preneel,
Intensive Program on Information and Communication Security, July 2006
• Google Images (most of the images)
• Sigridschrijft.be / Sony (Terminator 4 poster)