Software Engineering 3156

31-Oct-01

#17: Integration and Crypto

Phil Gross

2

Administrivia

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

3

Requirements Tweaking

Vision range Portal format Default Actor

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

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

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

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

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

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

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

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

OO I&I

Needed to include in a “Object Oriented Software Engineering” book

Basically, works the same as classical I&I

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

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

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

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

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

Metrics

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

19

Key Security Concepts

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

20

Privacy

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

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

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

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

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

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

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

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

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