Introduction

Document Sample
Introduction Powered By Docstoc
					Cryptology: Moving Forward,
Primitives for Secure Systems




                Dhiren R. Patel
Indian Institute of Technology Gandhinagar,
             Ahmedabad, INDIA             1
               Contents
• Cryptology Landscape
• Demanding applications <need security
  attention>
• Security Primitives, Processes and
  policies
• Examples
• Epilogue and Conclusion

                                          2
            Cryptology: Scope
• Understanding about a gap between
• efficient algorithms (e.g. for encryption) for the
  legitimate users
• versus the computational infeasibility of
  subverting (e.g. of decryption) for the adversary,
• how to analyze and break the provisional
  solutions?
• how to build protocols with security confidence?


                                                       3
     Context: Security - Goals
• Use primitives with certain special kinds of
  computational hardness properties to maximize
  the gap <e.g. Encryption Algo. / Hash Function>
• Application Engineer: It has to be secure, but
  otherwise as fast as possible
• Tradeoff between speed and security?
• Provide a graceful path for the future
• Developer/Designer: How many rounds do we
  need?
• "Hmm, not sure. Better double it for safety‖
                                                    4
          Information Security:
             Broad Objective
• to protect <information> systems against
  threats to the
• confidentiality, integrity, and availability of
  information and services
• Our challenge is to design systems which
  provably meet our definition of security
  and in which the operations are as fast as
  possible
                                                    5
      Security: Looking back
• The historical focus has been to try to
  build a ―wall of protection‖ around the
  system or network to protect it from
  external threats
• this approach worked when organizations
  were more centralized



                                            6
Paradigm Shift: Looking forward
• Today - employees, customers and partners
  collaborate in core business processes globally
  and across organizational boundaries
• Information-centric security binds security
  directly to information and the people who
  access it
• We need to ensure that they can access only the
  right information at the right time, when and
  where they need it <objective - revised>

                                                7
   Objective: Another Example
• How can we tolerate the attacks (or
  intrusions) into a database system in such
  a way that the database system can
  continue delivering essential services in
  the face of attacks and damage?
• How to define security in presence of a
  bounded/unbounded adversary?


                                               8
     Basic Security Primitives
• Reliance on Cryptography <for the
  protection of information and
  communications>
• Ciphers, One Way Hash functions,
  Trapdoor functions, Biometrics …
• Is Biometric Cryptographic???
• We may require to encrypt biometric
  templates!!
• It provides practical Security!!
                                        9
10
11
12
13
     Requirements Landscape
• Modules and algorithms to be used in a wide
  variety of products, including
• Secure Internet browsers, Trusted Internet
  Connection
• Secure Information exchange to space-based
  communications,
• Smart cards, Sensors <including resource
  constrained>, Storage devices,
• Security metrics compliances and products
  supporting PKI
• Social Networking and Security
                                                14
Applications: Security Requirement

• Confidentiality and Integrity
• Access control
• Authentication and Authorization
• border, aviation, maritime, and
  transportation security and physical /
  logical access control
• cell phones, mobile computing devices
  and portable memory storage
                                           15
Example: Personal Identity Verification (PIV)
           and Match-on-card
• Secure Biometric Match-On-Card
• E.g. indexing key, personal information of
  the user, details of electronic certificates
  and the biometric information
• to sign/verify and encrypt/decrypt email
  messages
• all communication of smart card assertions
  to the card reader be authenticatable!
                                            16
   Security App. – Coast Guard
• Transportation Worker Identification Credential
• a common identification credential for all
  personnel requiring unescorted access to secure
  areas of Navy-regulated facilities and vessels,
  and all mariners holding Coast Guard-issued
  credentials
• a tamper-resistant ―Match-on-Card‖ containing
  the worker’s biometric to allow for a positive link
  between the card itself and the individual
• <Ref: Mumbai Attack - 2007>

                                                   17
                   Banking
• Improving the identification and authentication of
  employees, contractors and users (mainly
  clients) for access to Banking facilities and
  associated information systems
• to enhance security, increase efficiency, reduce
  identity fraud, and protect personal privacy
• Verifying an individual's identity
• strongly resistant to identity fraud, tampering,
  counterfeiting, and terrorist exploitation
• Policy for a Common Identification Standard

                                                   18
             Health Care IT
• Medical information will follow consumers so that
  they are at the center of their own care
• Consumers will be able to choose physicians
  and hospitals based on clinical performance
  results made available to them
• Clinicians will have a patient’s complete medical
  history,
• Quality initiatives will measure performance and
  drive quality-based competition in the industry
• Public health and bioterrorism surveillance will
  be seamlessly integrated into care

                                                 19
Identity Management & Security
• Requirement: large number of unique IDs
  associated to entities <mostly human, and their
  ICT assets>
• Service Provider: Quickly searchable and
  verifiable, Authentication <Identification,
  Verification, Association with privileges and
  services, scope>
• Service Requester: Security against credential
  Theft, Quick Response Time, Anonymity <no
  trace left behind, not even to provider!!!>

                                                    20
  Security App. – National ID??
• A very large number of large-scale identity management
  systems (IDMSs) are being developed and deployed
  worldwide
• Why National only??? Why not Global ID?
• Potential interoperability issues
• Inconsistent and confusing formats
• Technical, operational, policy-related issues
• Are there any known attempt to fill in the gaps and to
  present the information about these systems in a
  consistent format that would enable research, trend
  analysis, and the development of metrics?

                                                       21
                  Global ID
•   Identification cards – Architecture
•   Generic card interface
•   Application interface
•   API administration
•   Testing
•   Registration procedures for the
    authentication protocols for interoperability

                                                22
        Identity Management
• Application: Seamless integration with
  appropriate separation – module handling ID,
  OS, Routing devices, Temp. data storage,
• Use and destroy, Minimal performance
  overhead
• Format and size of Digital ID????
• Use e-mail sort of token?? .uk, .in, .edu …
• <quick search through existing DNS tech.>
• Further taken to regional identification and
  further….. further…. Anonymity lost?? Easily
  predictable??

                                                 23
Attention to legacy applications
• Power distribution
• ATC
• Transport network
• Water distribution
• Space communications
<SCADA>


                               24
        example CSCI Module
• within a critical infrastructure control network




                                                     25
   CSCI Connection Management
      Layer (CML) for DNP3
• association between a master and an outstation
  should have information (at the master) about
• Master Identifier
• 16-bit Master DNP address
• Master IP address (implicit)
• Local UDP or TCP port number
• Outstation Identifier
• 16-bit outstation DNP address
• Outstation IP address
• Outstation UDP or TCP port number

                                               26
Recommendations: SCADA CSCI
• Secure Name servers based on IEC 61850 for verified object
  addresses.
• Individual stations to update the IEC 61850 Server with their
  configuration.
• Any needy station to obtain configuration and address of remote
  stations from IEC 61850 Name server.
• Station to obtain further security parameters from other security
  servers like DNP security rules server.
• Communication between a station and the security servers to be
  super secure.
• Cyber Security layer to be configured using the parameters from the
  servers.
• Cyber Security Layer to work independent of servers after
  configuration.



                                                                   27
Some known tricks – Processes
• Automated Combinatorial Testing for
  Software - construction of the results
  expected from a test case by exploring all
  states
• filter logic
• source code inspection - based on pattern
  matching or based on parsing


                                           28
   Known tricks – Processes and
              Policies
• to verify applications before making them
  available
• Security through Diversity – leveraging VM
  technology
• to confine applications that may contain
  vulnerabilities within a virtual domain into a
  so-called sandboxes – Java, VMware,
  User Mode Linux (UML)
                                              29
                 More tricks
• strict constraints - the system calls for untrusted
  applications
• Define three domains: base, trusted, and
  untrusted
• higher security based on multi-grained
  separation mechanisms
• processor-level separation (coarse-grained)
• OS-level separation (medium-grained)
• process-level separation (fine-grained)
                                                    30
 More tricks: Dynamic access control

• the access rights of processes can be
  changed dynamically to prevent the
  propagation, through Inter-Domain
  Communication (IDC), of viruses or other
  malicious attacks
• The access right of a process specifies
  which system calls the process can
  execute

                                             31
     E.g. Security at H/W level
• determine whether an access from a bus master
  to a bus slave should be granted or not?
• The decision is based on the access matrix,
  which stores information in which all masters
  can have read and write access to an I/O or an
  address range of memory
• In general, read-only data is often placed on
  ROMs


                                               32
       FIPS – NIST/NESSIE
• Standardization process
• It's hard to guess how much progress
  they'll make. We need to change this only
  once. Maybe we'd better triple it
• The possibility of extra rounds will only be
  available to the protocols that plan for it



                                                 33
                  Flexibility
• a good balance between additional flexibility and
  the costs of having a max that is too large
• a user-settable <flexibility>?
• a large set of useful differentials?
• graduated criteria,
• from least secure to most secure,
• to ensure flexibility in selecting the appropriate
  level of security for each application

                                                   34
                 Rivest: SHA3
• Deploy 3 candidate algorithms at the same time,
  including a switching mechanism,
• will be at most only marginally more complicated / costly
  than implementing and deploying one algorithm with a
  tunable parameter
• Users can choose as default any of the three they like for
  their application or platform or well-being.
• When security problems emerge for one of the three,
  users can easily disable it.
• switch can be made immediately, without noticeable
  effort or cost


                                                          35
                  Epic
• Abhimanyu in Mahabharata – fought
  through 7 layers – exhausted of time and
  energy eventually
• Single layer of stronger security??
• or Layered Security??
• or Security using Deception??
• Take cue from – for Reliability – use
  Biology <e.g. living body!>
                                             36
       From Where to Start?
• Define minimum information security
  requirements (management, operational, and
  technical security controls)
• Evaluate existing security policies and
  technologies
• Certification and accreditation process for
  information systems
• Information security training, awareness and
  education
• Solicit recommendations for raising the bar
                                                 37
          Example Solution
• Strict Read/Write sequences
• Timing window associated with operations
• Set up a chain of IP/MAC address <Strict
  path> before hitting the critical
  application/database
• Preparedness to Disaster, fallback policy
  and graceful Recovery <Process and
  Policies>
                                          38
         Concluding Remarks
• We all realize that computer security is a serious
  problem. But who should solve it?
• More precisely, who should be responsible for
  coping with computer insecurity—governments
  or the private sector?
• Perfection is great if you can get it.
• But most of the time, we must live with less.
• Computing systems are as good an example as
  any: they aren’t secure, yet we live with them.

                                                   39
        Concluding Remarks
• Information and information systems are
  critical assets that support the mission of
  an organization
• It gives more benefits with increased risks
• Information Security is about restricting or
  about enabling?
• If you eliminate all risks, you eliminate all
  rewards.
                                              40
  Concluding Remarks (Cont.)
• Algorithms never get stronger, they only
  get weaker over time!! Innovate!!
• When it comes to security innovation,
  don’t ask why it might fail?
• Instead, imagine why it will succeed?
  (RSA.com)



                                             41
            Thank you
   for your time and attention
 Thanks to ISDF2009 Organizers

          Dhiren R. Patel
IIT Gandhinagar, Ahmedabad, India
        dhiren@iitgn.ac.in
                                    42
   Vulnerability Assessment <Ref:
           CWE/SANS>
1. Improper Input Validation
2. Improper Output Encoding
3. Failure to Preserve SQL Query Structure
4. Failure to Preserve Web Page Structure
5. Failure to Preserve OS Command Structure
6. Cleartext Transmission of Sensitive Information
7. Cross-Site Request Forgery
8. Race Condition
9. Error Message Information Leak
10.Failure to Constrain Memory Operations

                                                 43
     Vulnerability Assessment
11. External Control of Critical State Data
12. External Control of Filename or Path
13. Untrusted Search Path
14. Failure to Control Generation of Code
15. Code Download without Integrity Check
16. Improper Resource Shutdown or Release
17. Improper Initialization
18. Incorrect Calculation
19. Improper Access Control
20. Broken or Risky Cryptographic Algorithm

                                              44
    Vulnerability Assessment
21. Hard-Coded Passwords
22. Insecure Permission Assignment for
    Critical Resource
23. Use of Insufficiently Random Values
24. Execution with Unnecessary Privileges
25. Client-Side Enforcement of Server-Side
    Security

                                             45

				
DOCUMENT INFO