1. Software Engineering 3156 31-Oct-01 #17: Integration and Crypto Phil Gross

2. 2 Administrivia There will be group reorganization Got a problem? Let us know ASAP Samples coming soon…

3. 3 Requirements Tweaking Vision range Portal format Default Actor

4. 4 Integration? Not really separate from Implementation, but traditionally thought of as such Schach calls it the “Implementation and Integration phase” Why? (2 reasons)

5. 5 Implementation needs integration (I) Here, a calls b, c, and d You can’t test a until you attempt to integrate with b, c, and d Code stubs of b, c, and d For b: need driver for a, stub for e

6. 6 Stubs and drivers Essentially empty modules Usually prints debugging info Stubs – Get called upon – Might return a canned answer Drivers – Call others – Also prints some debugging

7. 7 Implementation needs integration (II) Consider a really complex set of modules Each time you integrate, fault isolation becomes harder Additionally, possibility for faults increase Can’t work completely independently until the last day Even with OO Need to combine module and integration testing

8. 8 Top-down I&I Implement and integrate starting from the top Create stubs for subsidiary components Fill in the stubs later Good: major fundamental flaws shown early: better to test logic first

9. 9 Problems with top-down Difficult to test actual low-level functions (reusable components) – The top-level gets tested n times – Bottom-level gets tested once – Defensive programming a liability? if (x >= 0) computeSquareRoot

10. 10 Bottom-up I&I Build drivers, fill them in later Design flaws not shown early, but low-level components very well tested – Huge cost to redesign Conclusion: need to combine both

11. 11 Sandwich I&I Simple idea: work from both ends Tests logic, as well as reusable components Schach claims infinite upside from this model – Reality: a bit more complex to organize – Need both stubs and drivers

12. 12 OO I&I Needed to include in a “Object Oriented Software Engineering” book Basically, works the same as classical I&I

13. 13 Management issues during I&I What if the pieces don’t fit together? What do Phil and I do if server and client don’t talk? – Happens more often than you think… Have integration run by SQA – One well-contained group to integrate

14. 14 Testing I&I Incremental testing: as each new module is integrated, must already be tested separately, then continue testing GUI: can’t use simple test cases – Special CASE tools actually record mouse clicks, etc. Product testing when integration is complete, followed by acceptance testing

15. 15 Product testing SQA has to do extra testing, especially with COTS software – Alpha and beta phases With custom software, make sure acceptance test won’t fail: would be bad – Black-box tests for whole product – Robustness (crash?) – Constraints met (such as time bounds) – Documentation review Use “scenarios”

16. 16 Acceptance testing Does product satisfy client requirements/developer specifications? Supervised/independent SQA or client does this Must be performed on actual data Often, new product run in parallel with old for a while

17. 17 CASE tools Versioning and configuration management Build tools Environments: UI integration, tool integration, process integration: these support/automate the manual process – CMM levels needed Others

18. 18 Metrics Complexity metrics Total number of test cases and failures Number of faults/types of faults

19. 19 Key Security Concepts Privacy Authentication Authorization Non-repudiability Symmetric vs. Asymmetric keys Key management One-way hashes

20. 20 Privacy Social issues Carnivore, Echelon Linking of databases Surveillance Control over computer records

21. 21 Encryption What we usually associate with crypto Scrambling plaintext so that it’s unreadable Should be resistant to attacks – Even if attacker has unlimited access to plaintext/encrypted text pairs – Even if (especially if) encryption algorithm is known Do not try to invent one on your own – Rot-13

22. 22 One-way Hashes Also called Message Digests Like hash function, but less predictable Given a message and its digest, computationally infeasible to alter the message without changing the digest Encrypt digest with private key = electronic signature

23. 23 Public key crypto challenges Asymmetric encryption is very slow – Need large keys (128-bit or more) so that guessing private key is difficult – Solution: use a symmetric key to encode message, and then encrypt the symmetric key using asymmetric keys – Attach said symmetric key to rest of message Keys need to be trusted – Public key: man-in-the-middle attack – Private key: local machine compromise – Solutions exist for both

24. 24 Implications of public key Internet-scale cryptography possible Allowed for creation of tools like SSL, PGP – Encryption more powerful than government can decrypt – Significant social implications now Still, some problems – Government wants backdoors – Key trust: people do, blindly (including me!)

25. 25 One-way hashes Also called “message digests” Like a hash function, but less predictable Take a message and generate this “garbage” out of it If message changes, garbage will as well Difficult (impossible?) to reverse engineer garbage to original message Simpler and faster than encryption

26. 26 Applications of one-way hashes As long as you don’t need to know the original message… or already know it Signatures: create a digest of stuff to be encrypted, and encrypt it with private key – http://www.youdzone.com/signature.html http://www.youdzone.com/signature.html Crypt-ing passwords – You don’t care what the password is – If someone grabs the crypt, they can use it, but much more limited – Not at all foolproof, just limits damage

27. 27 One-time passwords Two mechanisms: – On an insecure link, once you log in, server changes password to the “next” one that you will know (or turns it off) Backdoor for emergencies, less used today with tools like ssh – Client and server generate unique digests