Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

Java Card Platform Security and Performance

Ad

1 Copyright © 2011, Oracle and/or its affiliates. All rights
reserved.
Insert Information Protection Policy Classification...

Ad

2 Copyright © 2011, Oracle and/or its affiliates. All rights
reserved.
Insert Information Protection Policy Classification...

Ad

3 Copyright © 2011, Oracle and/or its affiliates. All rights
reserved.
Insert Information Protection Policy Classification...

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Próximo SlideShare
First Steps with Java Card
First Steps with Java Card
Cargando en…3
×

Eche un vistazo a continuación

1 de 61 Anuncio
1 de 61 Anuncio
Anuncio

Más Contenido Relacionado

Similares a Java Card Platform Security and Performance (20)

Anuncio

Java Card Platform Security and Performance

  1. 1. 1 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Java Card Platform Security Eric VETILLARD Sr. Principal Product Manager, Java Card
  2. 2. 2 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Program Agenda • Security? What security? • Some Threats to Consider • Protecting your Assets • Protecting GlobalPlatform • Protecting the Virtual Machine • Protecting your Applications
  3. 3. 3 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Java Card is about Security • Java Card targets secure microcontrollers – Typically used as security tokens – Very often containing sensitive and confidential data – Very often controlling access to sensitive/valuable assets • Security depends greatly on the implementation – The Java Card Specification defines principles – A robust and bug-free implementation is required – In addition, security certifications are common requirements
  4. 4. 4 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Purpose of this Presentation • Identify some key security requirements for Java Card – Threats that are likely to be encountered – Mechanisms that require protection • Propose a few mechanisms/solutions – To enhance the security of a platform – To increase the platform developers’ awareness of security
  5. 5. 5 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Program Agenda • Security? What security? • Some Threats to Consider • Protecting your Assets • Protecting GlobalPlatform • Protecting the Virtual Machine • Protecting your Applications
  6. 6. 6 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Hardware Attacks • Power analysis – Leaking data by analyzing the execution – Many ways to exploit power analysis today • Following bytecode execution, attacking comparisons, etc. • Fault induction – Modifying the behavior of the platform – Becoming very accurate, better than hardware countermeasures • Not considering crypto attacks here
  7. 7. 7 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Software Attacks • Typical process – Loading a malicious application – Run the malicious application to perform attack • Systematically used in attack preparation – Attackers is a developer; possesses card management keys – Unverified applications can be freely loaded • Very uncommon in actual attacks – Attackers don’t have the real card management keys Attacking the Virtual Machine
  8. 8. 8 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Quotation of Attacks • A standard scale is used to quote the attacks • The scale is a combination of criteria – Criteria are applied on identification and exploitation From Common Criteria Elapsed time Hour, day, week, month, more, too much Expertise Layman, professional, expert Knowledge of target Public, restricted, sensitive, critical Access to target <10, <100, >100, too much Equipment None, standard, specialized, bespoke
  9. 9. 9 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Attacks to Consider Possible • Full flash/EEPROM memory dump – Very useful to analyze the platform and select attacks – Should NOT reveal any secret of any kind • Execution of illegal code in attacker’s context – A rogue application executing in its own context – But, it could exploit any default in your firewall • If that happens, other applications’ assets can be endangered • Basic SPA/SPA/fault induction attacks – Include enough redundancy and checks And to defend against
  10. 10. 10 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Program Agenda • Security? What security? • Some Threats to Consider • Protecting your Assets • Protecting GlobalPlatform • Protecting the Virtual Machine • Protecting your Applications
  11. 11. 11 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Remember the Objectives of Attacks • Disclosures are often considered the worst thing – Disclosure of a secret key – Disclosure of a PIN • Unauthorized modification is not good either – Modification of a PIN – Modification of a public key • Some other things may also be problematic – Accepting a wrong signature – Disabling a security counter What vulnerabilities are critical?
  12. 12. 12 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Protecting Assets is Essential • Instances of key API classes – OwnerPIN – All keys • Application data – Security counters • System data – Global encryption keys – Applet table and other meta-data What assets to protect?
  13. 13. 13 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Protecting a PIN Unprotected storage OwnerPIN 02 03 ref ref boolean[1] ptr F byte[4]] 01 02 03 04 PIN Try Counter PIN Try Limit Presentation flag (in RAM) PIN value (cleartext)
  14. 14. 14 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Protecting a PIN Protected storage OwnerPIN FD02 FC03 ref ref byte[1] ptr A5 byte[4]] 3E 82 47 8B PIN Try Counter (redundant) PIN Try Limit (redundant) Presentation flag (redundant) PIN value (encrypted)01 76 46F8
  15. 15. 15 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Protecting a PIN • Very bad: Obvious comparison – Compare byte per byte, fail on first difference – 20 tries on average to get to the correct 4-digit PIN • Bad: Full comparison – Compare byte per byte, always do full compare – Any visible trace of failure brings back to previous case • Better: Encrypted comparison – Encrypt proposed value, compare to reference – Then, any comparison will do: no leak on the value PIN comparison
  16. 16. 16 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Protecting a PIN • Protecting the PIN counter – Attackers will try to get more tries – Always decrement the PIN counter first – Be very careful about fault induction • Protecting against fault induction – Always verify the checksum – Read only once from memory – Valid for all data (PIN value, counters, flags) Everything else
  17. 17. 17 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Protecting your Global Assets • Some crypto keys are used to encrypt keys and PINs – These keys are essential for the platform’s security – Attackers will look for them • Be very careful with these keys – Always assume that attackers can get a full memory dump – Do not store these keys in an obvious way (16-byte chunk) – Try to diversify whenever possible Platform encryption keys
  18. 18. 18 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Program Agenda • Security? What security? • Some Threats to Consider • Protecting your Assets • Protecting GlobalPlatform • Protecting the Virtual Machine • Protecting your Applications
  19. 19. 19 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Why Protect GlobalPlatform? • GlobalPlatform is used to manage content • An attacker who breaks GlobalPlatform’s security – Can load illegal applications – May be able to modify some application’s data – May be able to modify some card-level secrets • The Secure Channel must be well protected – Especially if the Virtual Machine is not very protected The Key to your Cards
  20. 20. 20 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 How to Protect GlobalPlatform? • Content management (in the field) requires integrity • Make sure that integrity checks can’t be bypassed • Make sure that CLA tests can’t be bypassed The Secure Channel is the key 80 E6 04 00 Lc Data 00 … 00 00 E6 04 00 Lc Data
  21. 21. 21 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Program Agenda • Security? What security? • Some Threats to Consider • Protecting your Assets • Protecting GlobalPlatform • Protecting the Virtual Machine • Protecting your Applications
  22. 22. 22 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Which Protection for the Virtual Machine? • The Cost vs. Security balance is hard to find – Any additional check in the interpreter is costly • Illegal access to local frame is most dangerous – Especially is system frame data is in the stack • Alternatives may be possible – Organize data in alternative ways – Use the MMU to perform checks
  23. 23. 23 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Risks in the Local Stack LV0 LV1 LV2 Return PC Old TOS Old LV Old Context TOS TOS Accessible as LV3 Replaceable after pop …
  24. 24. 24 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Program Agenda • Security? What security? • Some Threats to Consider • Protecting your Assets • Protecting GlobalPlatform • Protecting the Virtual Machine • Protecting your Applications
  25. 25. 25 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Enforce the Firewall • Use the hardware protections when available – Isolation by MMU • Very efficient, not always really adapted • Requires the allocation of memory chunks (quota management) – Low-level encryption • With a specific key for each context • Very good compromise between performance and security • Make cross-context accesses highly redundant – Performance impact is minimal, since such accesses are rare Global system-level protection
  26. 26. 26 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Clearly Split Responsibilities • Make sure to follow well-known security guidelines – For both platforms and applications – Maintain the guidelines properly Platform and applications are complementary Java Card Application Developer Handbook Test and Inspection Process Interop and Security Guide Java Card Platform Defined by Issuer Applied by Providers
  27. 27. 27 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Q&A
  28. 28. 28 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8
  29. 29. 29 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Java Card Platform Performance Eric VETILLARD Principal Product Manager, Java Card
  30. 30. 30 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Program Agenda • Know your platform(s) • Optimizing Bytecode Interpretation • Optimizing Libraries • Optimizing Application Loading • Optimizing Your Applications • Limits of Interoperability • A Continuous Process
  31. 31. 31 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Performance is Complicated • Performs comes from a combination of many factors – Hardware performance – System software performance – Application tuning • Performance is only one of the parameters – Also consider security, maintainability, portability, and more • Learning to identify bottlenecks is a long process – When performance becomes an issue, it may be too late to start And often unpredictable
  32. 32. 32 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Measure Performance • Performance is an issue or will be someday – When your platform becomes more complex – When contactless requirements arrive • Prepare standard benchmarks – Using standard use cases – Using unit benchmarks to measure specific features • Run benchmarks often – Compare to competitors or to your older/other platforms – Monitor the evolution, and compare to your expectations Benchmarking is part of testing
  33. 33. 33 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Standard Benchmarks • Measuring can be challenging on standard machines – Timing is not precise enough for good measurements – For proper timing of specific features, use large loops • Measure the time of the loop minus the time of the empty loop • Divide by number of loops, and you get micro/millisecond precision • Check the Mesure Project (http://mesure.gforge.inria.fr/) – Plenty of tests available, together with a benchmarking platform
  34. 34. 34 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Differential Benchmarking • Benchmarks can contain measurement errors – A bug in the benchmark or in its exploitation • Comparisons are much safer – Even with measurement errors, comparisons make more sense • Comparisons are much more useful – It is normally possible to know what change is expected • The clock is going twice faster, so should the code – Comparing with expectations helps understand the possible issue Comparing is better than just measuring
  35. 35. 35 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Where is your Bottleneck? Bytecode; 20% Native; 10% Writing; 25% Crypto; 20% I/O; 25% Bytecode interpretation isn’t everything
  36. 36. 36 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Program Agenda • Know your platform(s) • Optimizing Bytecode Interpretation • Optimizing Libraries • Optimizing Application Loading • Optimizing Your Applications • Limits of Interoperability • A Continuous Process
  37. 37. 37 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Optimizing Standard Bytecode • Be careful with programming style – Method invocation can be expensive – Too much modularity can hide bottlenecks • Help your compiler – Make sure that optimizations are well performed – Force the assignment of key variables in registers • Assembly vs. C – Impact is limited if C code is designed for performance Limited Options
  38. 38. 38 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Focus on the Right Things • Bytecode interpretation is simple – A loop (don’t waste cycles at every round) – Many simple instructions (easy to optimize, assembly possible) – A few complex instructions (mostly object access) – Exception management (can be tricky) • Memory management is complicated – Object representation (optimizing the checks) – Memory structure and object allocation (critical in real use) – Caching, atomicity (reducing the number of write operations)
  39. 39. 39 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Focus on Mainstream Cases • Example 1: Firewall checks – Make the standard case (same context) as fast as possible – Second, focus on accessing system objects – For all other cases, performance is not an issue • Example 2: Exception catching – Exceptions normally occur in error cases – If so, no need to optimize this process: Errors will be slow – Don’t forget to tell application developers Unfrequent cases don’t affect performance
  40. 40. 40 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Program Agenda • Know your platform(s) • Optimizing Bytecode Interpretation • Optimizing Libraries • Optimizing Application Loading • Optimizing Your Applications • Limits of Interoperability • A Continuous Process
  41. 41. 41 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Beware of Java Layers • Example: The crypto library – The entire API is made of interface and abstract classes – Don’t use complex patterns for abstract classes • Signature.doFinal() should go straight to the computation • No analysis/switch/decision/abstraction at this stage – Crypto APIs may be used repeatedly with small operations – In such cases, the Java part of the invocation can be longer than the (native) computation itself – This should be measured during development Some constructs can be costly
  42. 42. 42 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Go Native? • When Java’s safety makes no sense • Util.arrayCopy() is the best example • If written in Java, 90% of the time is spent in useless checks • When a process is computationally intensive – Cryptography, biometrics, etc. • For security reasons (PIN checks, for instance) – To better hide the ongoing processing – To include specific countermeasures When to more from Java to C?
  43. 43. 43 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Going Native Securely • Perform all required tests – Example: Before to perform an array copy • Check both references as being of the right type • Check the size of both arrays • Perform the firewall checks • Then, do the copy (without redoing the checks at every operation) • There have been many implementation bugs in the past – Especially with missing/incorrect firewall checks – Consequences can be really bad Don’t compromise your platform
  44. 44. 44 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Program Agenda • Know your platform(s) • Optimizing Bytecode Interpretation • Optimizing Libraries • Optimizing Application Loading • Optimizing Your Applications • Limits of Interoperability • A Continuous Process
  45. 45. 45 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Is Application Load too Long? • CAP file linking is not efficient – The method component is written twice in EEPROM – The constant pool is written for nothing • Application loading usually in parallel with GP crypto – MAC computation is performed during the load operation The loading process is not optimized
  46. 46. 46 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Simple Ways to Optimize Linking • Keep the constant pool in RAM – If there is enough RAM available – Saves some useless EEPROM writes • Optimize processes – Optimize the number of write operations • Use the largest write cache page available – Try to parallelize I/O, memory writes • Forget interoperability – It is possble to drastically reduce the number of EEPROM writes Full interoperability
  47. 47. 47 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Program Agenda • Know your platform(s) • Optimizing Bytecode Interpretation • Optimizing Libraries • Optimizing Application Loading • Optimizing Your Applications • Limits of Interoperability • A Continuous Process
  48. 48. 48 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Know your Platform (bis) • Managing write operations properly – Persistent write operations are always costly – With atomicity, things are much worse – Developers should know what the best option is • Identifying bottlenecks – Some performance problems are usually known – Ensure that application developers are aware of them • Compare platforms Teaching developers to be careful
  49. 49. 49 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Beware of Java constructs • “Big” Java developers are used to JIT – Java’s inefficiencies are compiled away – No such optimization occurs on Java Card • Method invocations are costly – Getters and setters may not be such a good idea – Put some limits on the code’s structure • Virtual methods and inheritance are costly – In particular when interfaces are used – Don’t structure too much the code within an application Remember, no JIT on Java Card
  50. 50. 50 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Perform Local Optimizations • Use return; or break; as soon as possible – Avoid “goto” strings in the bytecode • Cache values and references in local variables – Computing obj[i].scp.key[j] is expensive • Two field accesses, two array access • Four null checks and firewall checks, two boundary checks – If you need it twice, cache the value in a local variable • Use exceptions for error handling – No cost on main (successful) case Local actions, global impact
  51. 51. 51 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Program Agenda • Know your platform(s) • Optimizing Bytecode Interpretation • Optimizing Libraries • Optimizing Application Loading • Optimizing Your Applications • Limits of Interoperability • A Continuous Process
  52. 52. 52 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Forget Interoperability? • The Java Card bytecode is reasonably optimized – Reduced instruction set – Combined instructions such as getfield_s_this • It is possible to go much further – The resulting code is not interoperable – Not acceptable for downloadable code – Not a problem for platform code or preloaded code In some cases, a very good idea
  53. 53. 53 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Forget Interoperability? • What ideas would be worth trying? – Optimize the instruction set aggressively – Use a different VM structure – Compile some code into native code • Some obstacles stand in the way – Such optimizations are usually costly in space – Specific tools need to be developed • These tools are often complex to write Some potential, many challenges
  54. 54. 54 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Closed Platforms • Some platforms are closed, “Java Card S” platforms – No post-issuance download (and install) of applications – Fixed set of applications • Such platforms can be optimized – No need for loader/linker or other post-issuance software – No need for full API support • The subset required for the fixed set of applications is sufficient – No need for binary-level interoperability • JCRE and VM can be optimized as required Reducing the footprint
  55. 55. 55 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Closed Platforms • We have released a Trimming Tool in SDK 3.0.3 – Analyzes a set of applications – Determines which APIs are required by the applications • Using the Trimming Tool on a platform – First develop a modular platform, from which APIs can be removed – Pass the TCK on the full modular platform – Then analyze the target applications – Generate the subset platform required for the target applications – Use this subset platform with the applications as a closed product Using the Trimming Tool
  56. 56. 56 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Program Agenda • Know your platform(s) • Optimizing Bytecode Interpretation • Optimizing Libraries • Optimizing Application Loading • Optimizing Your Applications • Limits of Interoperability • A Continuous Process
  57. 57. 57 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Performance is One Side of Life • Footprint – Size constraints are often quite tight – Platform code must be at least reasonably optimized • Security – Security constraints can be very invasive – Redundancy is bad for both performance and footprint • Maintainability and portability – Dedicated, optimized code is harder to maintain and port There are many other aspects
  58. 58. 58 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 The Doom Cycle of Optimization • Step 1: Implement without optimizing • Step 2: Add performance in the picture – Some things are too slow – Update design and go to Step 1 • Step 3: Add footprint in the picture – Performance optimizations made the platform too big – Update design to reduce size and go to Step 1 • Step 4: Add security to the picture – Security countermeasures make the platform too big and slow – Update design (or redesign completely), and go to Step 1 Failing without grace
  59. 59. 59 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Consider All Constraints First • Consider all the constraints at once – Understand that “just enough” is not enough • Some time will be wasted by security, require 20% better performance – Use a secure design rather than a secure implementation • Example: Increase PIN counter first, compare encrypted values • This is not easy: Requires architecture skills – First time will be difficult – Subsequent times will be easier, as experience grows
  60. 60. 60 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 Q&A
  61. 61. 61 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8

×