Jack Selby – Lessons from Paypal
Ron Rivest – Peppercoin Micropayments
Loyalty & Micropayment
Systems
Zulfikar Ramzan & Craig Gentry - Microcredits for Verifiable Foreign Service Provider Metering
Stuart Stubblebine – Addressing online dictionary attacks
Lawrence O’Gorman,
Smit Begga, John Bently – Call Center customer verify. w/
querydirected passwords
Jaques Stern - Cryptography and the French Banking Cards: Past, Present & Future
Simon Pugh - Security & Risk Management for Transactions for Paypass
Aggelos Kiayas - Vector Ballot E-voting Approach
Jens Groth
- Efficient Maximal Privacy in Boardroom Voting and Anonymous Broadcast
Building Usable Security Systems
Andrew Patrick - Usability & Acceptability of biometric security systems
Jean Camp – Risk Perception Failures in Computer Security
Bill Yurcik – Visualization Tools for Security Administrators
Ka-Ping Yee – Principles of Secure Interaction Design
Jon Peha – Bringing Payment Technology to the Unbanked (Cyphermint)
Koutarou Suzuki - Secure Generalized Vickrey Auction without 3rd party servers
Moti Yung w/ Elisavet Konstatnou et al - Electronic National Lotteries: Design & implementation
Helger Lipmaa w/ Edith Elkind - Interleaving Cryptography and mechanism design: Online Auctions
Giuseppe Ateniese and Breno de Medeiros – Identity-based chameleon hash and applications
Game Theoretic & Cryptographic Tools
Vanessa Teague - How two selfish players can select correlated random actions
Pino Persiano - Efficient and Usable Multishow Non-transferable Anonymous Credential System
Mix Networks and Anonymous Communications
Opening Remarks
Hilde: Announcements: Cocktail reception beachside 5-7 Wed, Tuesday General meeting 8-9, after which rump session
Ari: Tradition
of having FC on tropical island. We tried to get the
He’s not a cryptographer or technologist, but was employee #9 at paypal. Raised financing ($20 million/month burn) had to deal with regulators. Now with Clarion, a hedge fund/VC office.
Priority #1 for any scheme: meet demand from both buyers and sellers.
Payment scheme is a chicken & egg problem:
Consumers have to trust it, merchants have to accept it.
Paypal came about when VC was plentiful—had the ability to get product out there.
(Gave people $20 to sign up).
Market was dense, online, unexploited, sophisticated: online auctions.
Merchants had high cost of CC purchase
High fixed costs (diminishing MC) for small-medium sized merchants
Innefficiency inherent in CC space
Q: why not pc cc processing SW?
A: still have huge fraud costs
Priority #2: reachable, scalable markets
Great partitioning slide of mkt graph: size of receipt by risk/immiediacy of transaction
Friend-friend : pay w/ cash
Long term relationships (landlords, doctors): checks
Person-person(less trust): western union
Large merchants: credit card
Paypal: small businesses & auctions
High risk merchants: adult, gaming –
Tapping an inelastic demand curve
Initially, gave it away for free
June 2000: started charging for it, and kept increasing price
à no drop off in usage à inelastic demand
[Inelastic demand curve means that
consumers will continue to buy even if prices rise]
Execute and focus on a business model
Caveat: “We didn’t really have one at the beginning”
profitable business model meant: had get consumers away from funding acct w/ cc
Driving costs down
Businesses pay (must pay?) to use the system
Drive revenue up
Evolve technology to meet needs
Technology
was only 4th priority
Random deposit: send two random deposits to authenticate <email, acct #>
Outsourced authentication to customer service of the banks
(much to their displeasure)
Skewed the random value to avg $.30 to save $
Fraud inside and outside
1.23% fraud in 2000
had to implement inhouse fraud protection
lots of inhouse data, mine it!
Competition
Working with banks & consortia was a nightmare
Any
business model that is dependent on banks is dead in the water
BUT: competing with banks is great!
V/MC could have shut them down easily
They just weren’t in an innovative frame of mind
Why have other schemes floundered?
1. Poor platform choice: (paybox – several SMS payment messages)
2. Non-need for consumers & merchants
Amex Blue Card: premised on online purchase exclusive
Beenz/Flooz: no money to overcome chicken & egg
3. Poor marketing
eVisa, Secure MC: marketing by fear online
like selling a house in a bad neighborhood by claiming is
has good bars
Promising payment schemes
Gov’t IDs – smart cards
Online “online” debit
Need to protect banks from fraud
Have to work with banks
Online markets with scalable, inelastic demand
Music, gaming
Q: gaming market size? A: dunno
Q: how are people paying now? A: based outside US, can’t come back
Q: why not go after western union? A: they’re trying to ignore destination
Conclusion: don’t let technology tail wag the dog of the
business model
Q: How much did you spend on customer promotion?
A: Raised $200 million, probably $40 million went in
Stuart: people are buying stupid security snake oil for FUD, even though it doesn’t make sense
A: selling a sort of insurange
C: for banks, “fraud is a client” –moti yung
Q: regulatory concerns
A: 1) just a money transfer and 2) a reliable money transfer (state by state) 3) PATRIOT
Q: gaming regulations
A: Only spitzer seemed interested in enforcing wire transfer
Q: How did forming relationship w/ ebay work out?
A: Worked with Marty Hellman to get product to beam funding over Pilots
Marketed with “Scotty” – “Beam me up”
Built in functionality for “what if he doesn’t have his Palm”? – use email
Realized that the email piece was better
Ebay had a Billpoint technology, but allowed paypal to muscle in
“cash registers at auctions”
Could have driven them out by being mean, but worked out a deal
Peppercorn is the smallest amount for contract payment in English law
Micropayments
Small enough that transaction costs matter ($.01-$10), avg $.50
Lydians invented coins ca. 640 BC
Before then, small purchases difficult w/ gold bars, etc
Analog today with CC
Generic payment framework
Cust Alice, Merchant bob, with their own PSPs (banks?)
1.
2.
3. bob deposits
4. Bob’s
PSP settles with
5.
How we’ll make small payments
Web downloads
Apple is proving market exists, but isn’t making $ b/c of transaction costs
Mobile phones – maps, ringtones
Aggregation
None – inefficient
Chaum (benefit: it’s anonymous)
Merchant level – depends on consumer demand, only works sometimes
Itunes: Wait to see if customer will make more purchases
Barrier of total single consumer spending
MicroPSP –
Centralized micropayment server as an added mech
Additional complexity
Kind of paypal mech
Doesn’t scale as well
Universal (peppercoin) – driven by savings for merchant
Merchant prefers $0 for 19 payments and $10 for one to 20 $.50 payments
Given transaction costs
Merchant samples revenue stream: law of large numbers
BUT: consumer MUST only pay for what spent
Each payment has an assertion for cumulative payment to merchant
Gets billed for total amount spent at all merchants
Also works for offline accounts
Q: how does
A: check inconsistencies, w
Will later be able to protect consumer info from tampering
(Mention of DRM sets of rumblings from the mob)
Q: What tech is pushing what?
A: any fraud will be manageable
Q: Can I double spend?
A: payments are ‘electronic checks,’ can’t be transferred, but do want to have a receipt
Q: Chargebacks?
A: need to push it back on the merchant in an automated way (customer service, esp)
Q: can
A: needs a very slow information rate if consumers only see bills once a month
Q: do we need additional information mechs to do all the error checking you’re thinking?
A: no.
Not a new currency, but extending existing payment mechs to micropayments
Lots of activity below radar of existing, occasionally kicks up to even out
Dimensions of problem
Aggregation
PSP online
Interactive or non-interactive (anti-spam payment)
Q: spammer generates 10 million messages, ‘pays’ but then defaults à no payee recource
C: model depends on a limited # of merchants, won’t work for spam
A: can misuse a credential [so can be defrauded as before]
BUT: can detect some fraud automatically
Previous work
Lottery tickets: interactive protocol of collisions of hash: merchant “wins” payment
Non-interactive: use deterministic digital sig for collision
Computational cost: getting cheaper
Online/offline precomputation
Variable-sized payment: need to convert probabilities based on size of transaction
Is revenue variance an issue?
Cost savings make up for statistical variance
Fraud models for peppercoin
PSP only has partial information
Merchant and consumer can collude
Q: Transaction cost is because market will bear, not actual cost: it’s a marketing issue
A: Debit cards make
Foreign service phone providers can
lie about how much roaming minutes were used
Simple approach: hash chain is signed, given to cell phone
Foreign service provider (FPS) checks the hash, adds new value
Home service provider verifies chain
BUT: hash chains are linear, can get long
Design goals: FPS and HSP shouldn’t overcharge user (proof)
No undercharging consumer either
FSPàuser shouldn’t do too much work O(1)
Minimize communication between user à FSP O(1)
Proof size is log t
Related work:
Hash chains for micropayments, paytree
Micropayments for wireless
Quasimodo tree
Leaves are assigned random values, hashed up to a root (like a merkle tree)
BUT: can get values in the tree with some set of nodes
FSP stores some node values over time, making each add’l query fast
Smaller tree, credit size, verification time than merkle trees
BUT: cache stored by FSP
Not that bad: 3 hours capacity for 5000 users: 100 M
BUT: larger packets sent
It’s a microcredit system b/c users pay “tokens”
If good assumptionsà can prove no overbilling or underbilling
Extensions
Polling to reduce computation, but increase risk of fraud
Group signatures
Loyalty program: means to achieve customer retention
Guarantee
future earnings (lock in)
Better resource planning
Customer Retention even harder online: customer fluctuation high, easy to shop around
Reward “loyal behavior”: strong preference, repeated xanctions
Buy X, get 1 free
FF miles
Privacy issues
Require customer identity, managed by vendor
Reqs for electronic privacy loyalty systems
Privacy
Must not be possible to link issue processes of loyalty points
Purchase must not be linkable
Security
Customer can’t make loyalty points, can’t double spend them
Pooling
If customers can pool benefits, merchant doesn’t get as big benefit
Different from collusion: multiple buyers sharing same ID
Counter scheme
No central repository: each cust has a counter
Better than tokens b/c of only one object
Have to hide value à use elliptic systems
Process
Initialization
Choose a curve, and a secret key
Purchase
Issue ith loyalty point
Send blind counter to merchant who signs it
Updated counter returned to customer
Customer verifies w/ properties of elliptic curve
Redeem rewards - unlinkable
Security against pooling
Incremental Diffie-Hellman (iDH) problem defined
Random oracle model
Need b to the 2 to the n
No alg known that allows this problem in parallel
Power b is unknown
à not possible to pool
Vendors can detect previous use
Q: What about the pointer that I got the 95th point after I spent a full hundred?
A: The history of the token becomes invalid when spent: can’t spend same S twice
Q: If customer loses serial number, is it recoverable?
A: no. Vendor doesn’t have anything recoverable
Q: Business model?
A: … Privacy more important than consumer data?
Pinkas & Sander’s login protocol
Human in the loop, reverse turing tests,
Problem with passwords
Insecure when generated by people
Unusable w/ good security
Vulnerable to automatic dictionary attacks
Account lock-out à support costs, DOS
Naïve attempts
Get Reverse Turing Test (RTT) for each id/pwd entry
Or just on some tries
Can’t just get RTT for correct pwd entry
Attacker typically has multiple attempts
P & S
Enter ID, pwd, cookie (if present)
If id/pwd correct & cookie valid à enter
If cookie not valid, get RTT
If pwd wrong, ask RTT with 10%
Say that login failed
Modifications
Reduce threat of cookie theft by only storing cookies on “trusted machines” (?)
Have a non-owner mode that user can set
If cookie not valid: check # of failed login
If not in owner mode, and have few failed logins à get in with RTT
If password fails, give RTT if multiple attempted login
After I’ve failed pwd a bunch of times, need an RTT each times
w/ cookie, never get RTT with
non-ownder mode, threshold applies
Cookies not stored on non-owner operated machines
Parameters can be managed dynamically
Relay attack on RTT-based login protocol
Malicious adversary has naïve user answer others’ RTTs with
Soln: Embedded warning
Sweatshop attacks
Soln: notification of failed logins
BUT: help desk support req’d
Improvement: attacker will answer some RTTs no matter what
Need better metrics for security vs usability
Q: can it be used for DOS?
A: yes, but can balance, and ramp up time
Q: how many people
fail RTTs?
A: we don’t know
C: RTTs getting harder
Problem: eliminate personal information in customer verfication
Costs money in terms of man hours, stored data, etc
“Secrets” are standing targets for attackers
Learned by agents
Heard by eavesdroppers
Not private according to HIPPA
Specifications
Convenience is most important
Low cost
Secure (anything that’s an improvement)
App: health insurance & financial call centers – telephone is still needed
Tech: phones
No computation
Plain text
User authentication
What you have: Tokens are expensive
What you are: biometrics are unreliable (talk to him afterwards)
What you know
Push: memorize password (people are annoyed)
Pull: something that is always there
Traditional (mother’s maiden name)
New (this paper)
Related work
Incremental Personal question
Incremental Challenge-response
Often image based
Query-driected passwords (QDP)
N questions
M multiple choices
User selects n questions to answer
Some are better than others
Not as vulnerable to brute force
Not as vulnerable to eavesdropping
QDP + something
Phone in & authenticate for the question
Question sent to phone, which is used to answer question
à Token
Client stores info: Wallet card
Enroll
Wallet card as a codebook
Card helps user get keys to answer questions
Text + index
Uses an interactive telephone agent
Usage results
Recall rate: 92-95%
Not pure data on imposter rate
Obviously: closer you are to a person, easier they are to imposter
Soln: use different epochs in their life
ALSO: if I’m close to some one in general, can get maiden name etc
10 minutes for users to enroll – people hate it
Verification: 1-2 minutes
Open research
Answer distribution: want questions with close to uniform prob
Entropy vs. keyspace
Know that a smart attacker will never choose the low prob.
Information extraction
Need numbers that are not searchable through databases
Question authoring
Q: personal information release makes people uncomfortable
A: consumers can not answer things, 3rd party doesn’t require answer to all questions, consumer can choose which to answer a priori
Q: for verification, people lose patience after 3
A: these are people who need passwords for pwd recovery, enrollment is 8 questions
Moti Young: Rump session announcement;
Introducing Jaques Stern: He was a
mathematician, who moved into CS, and actually started to do CS. Excellent
advisor to many students, great work in cryptography,
consults with the French Government: instrumental in opening
Slide: A Frenchman with a banking card as a diver off
History of the French banking cards
1967 – plastic cards
1971 – magstripe cards
2 tracks: ISO1, ISO2
Main data (in clear)
Primary Acct Number (PAN)
Expiry data
Service data
Crypto
Enciphered PIN code
3-DES MAC (card verification value)
Magstripe attacks - Stripe can be copied
Physical additions to an ATM machine w/out users knowledge
Magstripe reader over insert slot
Camera to view PIN entry
Can manufacture another card
1990-1992 – moving to chip cards (“Going the French way”)
Takes 2 years to phase in new technology
Put chip into IC module, put it on a card, add data to plastic, stripe, chip
Non-crypto security measures
Security also lies in contract regulations and criminal law
Protections for liability
Laws against fraud as a deterrent
Visual devices for merchants to recognize fake cards
Printed security code on back of card
Although: Security code is crypto-generated
Fraudulent use detection w/ scoring systems
Chip security - Certified by Common Criteria, standardized HW security
Crypto Security 1990 – B0’
Offline authentication
PIN code
Transaction logs w/in card
(triple) DES
Chip-terminal dialogue (“Please think about flaws”)
Card presents itself w/ card #, authentication value (RSA sig of PAN)
Terminal checks sig
PIN code is sent to card, which checks against card
Card 3DES
signs transaction information (sym cryptogram)
Terminal sends cryptogram to authentication center
1998 Humpich case
Humpich manufactured a card, used it in an offline context
Claimed that he had subverted the Great French Plan, but he wasn’t smarter than us!
Flaws with 1990 plan
Circumventing RSA: RSA was 320 bits
Humpich found factoring program, got RSA modulus
à Now they use 800 bits, soon to be 1024
Circumventing PIN code: yes cards automatically say that they are
Says ‘Yes’ when I enter the PIN
W/ a copied RSA signature
à Go online more systematically, or all the time
à Quick detection
à blacklist bad cards
à migrate to DDA
EMV & Dynamic Data Authenication (DDA)
Designed by
V/MC, will be deployed throughout
Challenge response
Card signs challenge w/ private key
Provide Cert of issuer signed by matching public key
Terminal checks cert & signature
Cross-border fraud
Have to use card in a country w/out chip capability
Not breaking crypto, but bypassing
Card Number capture
Merchant theft, theft from merchant
Crypto can’t do much
Crypto 20 years from now
Very large RSA moduli?
Elliptic Curves?
OR: only symmetric keys for all transactions online
French people now carry 2 crypto processors all the time: GSM phone, Banking cards
DDA has good security, remaining attacks bypass crypto
Q: Attempts to present multiple pins for yes cards?
A: no, it’s customer service hassle, PIN isn’t really crypto
Q: What happened to Humpich?
A: Convicted, suspended sentence, wrote a book
A: (from above talk, based on his work) Mgmt for PK & EMV: issuer keys aren’t on terminals, but V/MC list of keys is
BUT: - I’m not talking about EMV cards, but I am talking about Paypass
Contactless smart cards
A response to transponder systems like EZPass, key-fob gas payment systems (speedpass)
All tie to credit card at the end of the day
Phones also have been proposed as the primary payment device
US market
Huge size, huge Infrastructure investment
National mechanism to do something is hard
61% of consumer payment still conducted w/ cash & check
Designed for small ticket price, to replace cash products
(don’t want to cannabilize own products)
Improve convenience, speed, better than magstripe card
Design issues
Keep in mind EMV migration, high phase-in time
Need low incremental costs for tokens, acceptance scheme
Want a brand presence, leverage existing infrastructure
Trials
Paypass
ISO 14443 standard – familiar, already deployed
Token isn’t powered (Passive RFID)
Time of .3 sec to read
Proximity design to be about 5cm
Risk assessment – shouldn’t present more fraud than magstripe card
Eavesdropping – genuine transaction could be overheard by rogue terminal
Similar to magstripe skimming
Can eavesdrop from about 20m, depending on POS term, antenna, noise
Pickpocketting - Someone does a fake transaction with card w/out knowledge of reader
Can build a big terminal w/ 1.5m range ($25,000, not portable)
(Many comments about how to hide it)
C: privacy issues as well.
Cloning, and reusing in different channel
Countermeasures
Prevent attacks by protecting interface
PKS would be expensive, hard to fit on transponder, hard to manage
Make attacks useless by making data unusable
This approach will be better
Terminal must differentiate how card was read, so people can’t clone online
Send account data + dynamic CVC3 calculation
Magstripe Dynamic CAM principle
Terminal creates unpredictable number, send it to card
Card creates unique CVC3, using number, card data, secret 3DES card key
Card sends CVC3 to terminal
Terminal updates CVC3
Terminal checks transaction with issuer
Q: If CVC3 is only 3-5 digits, can you search the space?
A: It’s stored in decimal values, but yeah.
Q: why did you use the DD field?
A: nowhere else to put discretionary data in existing protocol
Fraud scenarios
Eavesdropping: Fraudster can’t reuse CVC3 because card will detect it
Simple pickpocketing: terminal supplies UN that won’t match recorded reply
C: merchant fraud: some one leaves their term set for $20 for all passerby
A: merchant fraud can be detected, prosecuted
Cross-contamination: we check for this, since paypass has unique feature
Steal paypass data, try to create magstripe card
Focus is on detection, rather than prevention
Detection prevents reuse
Q: Regulator issues
A: will roll it out, work with other cards, standardize for interoperability
Q: Cross-contamination: what is impact of field on other magstripe cards
A: fields don’t impact other stripes
Q: Privacy issues
A: Reader distance is important for legit; what can illicit users really do?
Improvement over
Q: Can people have a protection?
A: wallets
Q: Time?
A: They shaved several seconds at McDon for the total transactions
(Had to tinker with placement to prevent SUVs from knocking it down)
Q: Backup for payment failure?
A: Deploy as dual-use for card as well.
Three basic approaches to evoting
mix-net (chaum)
homomorphic encryption (benolah)
Blind authority
3 basic properties
Universal verifiability – anyone should be able to verify that the tally includes all votes
Efficient Tallying
Writein Capability – voters can submit any value, not just value from a set
(Also, privacy, prevention of double voting)
Question: How do the three basic approaches perform with three basic properties?
Mix-net - Mix encrypted ballots in many mixers
Voter privacy and double voting are handled (mixers don’t collaborate)
Writeins allowed
Mixers must prove that they didn’t affect any ballots
BUT: efficient tallying takes a
Homomorphic Encyrption
Voter gets a PhD, proves that ballot if formed properly
Votes compressed into single cyphertext
Decrypted by a set of authorities
Privacy, double voting handled
Efficient, verification are good
BUT: no writeins – inherent in design of compressability
Blind signature - Blind authority signs ballot, eliminates double votes
Votes aggregated through anon channel (like a non-robust mix-net)
Writeins allowed, efficient tallying
BUT: universal verifiability
Need to have voter check on the output
SO: no evoting technique satisfies all three things we want
Machinery
Homomorphic encryption doesn’t give us writeins,
Mix-nets are too hard to tally
Vector ballots – 3 submission components
Have a homomorphic encryption function E
Predetermined candidates all have numbers
Choose candidate: encrypt his/her number, and other 2 values are 0
Choose writein: encrypt 1st value 0, second 1, final is writein value
Mutual exclusive writein/candidate selection
Voter must do some work to prove value is good
Voting w/ vector ballots:
Break ballot into the 3 components
Use homomorphic enc. to compress other ballots
Can easily get candidate winner
Write-ins: Shrink & mix-net (new notion)
Can find out whether a bunch of ballots have a write-in vote
Privacy contained by having a big group
If 1% votes are writein, 20 ballot batches: can throw away 81% of batches
Now we can use a mix-net
Not time-sensitive at this point
Other issues
Need the capacity of compression mech
Anon broadcast: N players each have a vote they want to say, w/ anononymity
Election privacy: vote1 = result – sum(other votes)
Conditions
Perfect ballot secrecy: coalition information à own votes & result, not other votes
Self-tallying – result reveals itself
Dispute-freeness: dishonest behavior detectable
Assumptions:
BBS – permanent, public message w/ known author
Phases and stages, possibly controlled by adversary
Protocol
Registration: Each player registers a key Xi
Voting phase: cyphertext is modified
Each voter uses key, adds his own vote, rerandomizes the cyphertext
Complexity
O(1) key generation
O(n) verification of proofs
Voting O(log c)
Verification O(n log c)
Security
We cannot guarantee security only after all voters have announced their vote
Andrew Patrick:
Sampling of usability research: how do we make security
systems more sensitive to the way people work?
We’ll have brief presentations and then discussion
Human Factors – anything that involves the user in any way
Technology
Users – memory, motivation, can be rational, physical characteristics
Goals and tasks – usually the focus is on goal, security is secondary
Context of use – physical location, identity, embarrassment.
Many metric methods
Drivers increasing usability
Sensors are better, cheaper, more robust – each can be bought for $100 or less
More transparent to users
Getting
associated with access control
Concerns are performance, accuracy/convenience trade-off, physical characteristics like aging
Research being done on usability
ATMs
Anthropometric studies: locate eyes
Design: finger swiping for fingerprint
Field trials for iris recog was highly accepted
à false rejection has to be 0!
Iris scanning: need to look at image and scanner at the same time?
Ergonomic issue for fingerprint scanners
People need feedback for these systems
Acceptance drivers
Technical interest
Identity theft fears
Memory load – people aren’t good at memorizing things
Concerns about acceptance
Benefits not evident, esp. because you can’t transfer permission
People don’t see dangers of pins, think that they will cheated
Worried about public failure = emberassment
Privacy: can we get original image from digital template
Canadian study
Didn’t know what biometrics were
Have worries
BUT: it will help, is coming anyway
Fundamental issues:
They’re unique
Need a live-test
Covert use
Single-use biometric system – tie fingerprint to a single application
Metaphor: need to communicate environmental risks to people to change behavior
Paint thinners are known as bad, household cleaners are as bad
Need to link the two
Mental models – what do metaphors imply about problem and response
Market failures – costs and downtime
Need regulated market, liability, insurance, incentives
Crime or war – attack, defense, perimeter
People think they can rely on defenses
A failed model for end users
Soln: Go shopping if you’re in the
à Direct mandates, law enforcement
Illness – virus, infection, epidemics
à computer hygiene, “public health” information
This is what we want: simple things that you
have to do
Better
than market failure
No
one says “I’m not going to get the flu because I have no assets”
Animals – bugs, infestation, monoculture, swarming
à Constant monitoring,
weeding, animal control
biodiversity is good.
Case studies:
The Love Bug – disease, everyone knew they were vulnerable
Used social networks
Law Enforcement result – no law = not a crime
No economic incentive to perpetrate
Epidemic model
Transmitted from people
Wash hands = don’t open attachments
Slammer
User had no knowledge that they were at risk – who knew they has a SQL DB?
Could have been detected at network level – distinct UDP packet
Like a public health epidemic
LE failed – 2 terrorists groups (falsely claimed responsibility)
Blaster
Attacked the immune system itself
Worm-blast – tried to fix people à cowpox
Sobig
Economic incentives – helps spammers
BUT: still a public health problem – can’t get known victims to stop
SoBig II
Victims were unknowingly breaking law
One arrest,
but he was an idiot
Problem:
We see ‘virus’ think ‘malware’ see ‘computer crime’ think ‘malware’
Public sees ‘virus’ thinks ‘health issues’ sees ‘crime’ thinks ‘risk’
Different models suggest different responses
Economics can communicate the wrong thing to end users
User response
Download – inoculation
Push – crime & surveillance (cops will take care of us)
Metaphor of ‘digital signatures’
No revocation, no agency questions
NCSA – want to protect supercomputers
Active security research program
Sys admins are users, too
Security is a huge n-dimensional space
Problem isn’t lack of data, it’s using the data
What we can see
Granularity for productivity, but visualization to make it useful, easy to understand
(colors for trends)
Key for inferences for action
Applications
Forensic analysis
Vulnerability analysis
Trend analysis – profiling
IDS/ anomaly detection
Intrusion detection
Binary when you know what you’re looking for
Efficient, but scalable?
Visualization
Visualization is very powerful, can absorb lots of data in movements, colors, etc
“When you don’t know what you’re looking for”
Examples
Colored, 3d histogram
Colored 3d grid, with attack tracking from above
NvisionIP
Ben Schneiderman = overview and have ability to zoom in
Can filter overview
Zoom into subnet, get port activity of specific machine
Visualization pitfalls
Human perceptual limits
Apophenia – see patterns when there aren’t any
Cultural/organizational biases
Data-centric vs problem-centric visualization: excel won’t always be best
[See his handout, on the web at http://zesty.ca/sid]
What happens when you try to design user interfaces?
Security is about dependability
Specifications change over time
Can’t depend on experts all the time
Usability and security depend on each other
Not usable w/ out security, secure w/out usability
Pop-up dialog as an example of bad usability (“ambient authority”)
Better: use a designed window to integrate permissions
How to manage authority if you don’t know what authority is?
Summary of principles (see handout)
Examples
Paypal: indicated that transfer happened, have money in account
BUT: paymet was withdrawn
Problem: user had expected ability that was false
Cyphermint: Can enter different acct # from who I’m actually trying to pay
Also can be forced to accept multiple ‘Bob’s
Problem: identifiability is problematic
Q: Public health & security – should we have counter-viruses from the gov’t?
A: We have mandatory inoculations for kids, but even that’s hard to enforce/enact
That, and it’s a bad idea and wouldn’t work
Only a few cases of forcing people to accept treatment: we accept autonomy
Q: What about false analogies, taking too much from metaphors?
A: people always take too much.
See “Mental models of risk”
Q: You’d think education would help, but researchers say that
A: Not perfect, but idea is the responsibility of risk
Q: What is the status of IPnvision, and what can you find in the logs that you can’t see
A: Can always find something in the logs if you look hard enough
Vis. is like grepping, but can see things faster
Metaphor: flying by instruments vs. flying by sight
Q: Usability & security complement each other sometimes, but may want certain user behaviors
--such as anon: want lots of traffic, but also want them to act the same way
A: Users act from motivations, and address the motivation
Q: Why are these usability problems still there—they seem so obvious?
A: See security & usability as add-ons in the development process
C: Many people consider themselves experts
C: Problem: conflicting objectives
Cyphermint: Want to be able to send $ anonymously if they like
Agenda was circulated (Official minutes available from IFCA
secretary)
President: Jean Camp
Four issues – if you have an opinion, email board
Where to host DNS
Where to incorporate
Taking money
Non-profit issues
Secretary: Hilde ten Berge
Proceedings mailed
Minutes filed, all in accordance to w/ Aguilla law
Contact her for membership information
Thursday morning: will get survey & list of participants
Treasurer: Ray Hirschfield
Just took office, but waiting for audit results
Audit results: Made money in 99 & 00, started losing money in 01-03
Lost money b/c of fewer corporate registrants, fewer sponsors
Stuart: cash balance? A: $40K (gains + losses)
Andrew: Attendance? A: We bottomed out last year, attendance may climb again
Nomination &
Election of Directors (Markus)
Discussion on rules: nominate anyone in the room (no seconds)
Every
nominated candidate gets 5 min
Vote on candidates
Statements of those already nominated
Ray: glad to see new faces, hope to build attendance
Broaden field to appeal to finance, banking, policy aspects of crypto
Not just math
BUT: keep a cryptographer as chair, other good bits
Respect wishes of membership
Did
not vote for bringing conference to
Tried to get new people involved, I can maintain continuity
Include and support women in the field
Jean: Conference with good papers, low acceptance rates
Security is not just a process
Broaden focus, expand it & make it more well known
Responsiveness, growth
Markus – will nominate self, give rump session talk, then withdraw
We should think about WiSe04 – Wireless Security
Should have greater crypto focus
With MobiCom, September, East Coast
CFP: June 30
Withdraw nomination
Ari Want to be more than 2 choices
Support Jean & Ray
Would like to expand into Financial Data Security, even change name
Discussion on voting process – not resolved
(Hey,
it’s
Markus offers slightly less-than ringing endorsement of Ari as too stressed
Long Term Planning
(Jean)
Please volunteer to help out with the planning of reincorporation
Poll (non-binding)
No
objections to leaving
A
few objections to reincorporate in the
Ongoing Audits
They are an expense, but they bring value
Q: how much is the cost?
A: $1500/year to get source data (3%)
C: get a part-time accountant
C: as a non-profit, going to have to get audited anyway
Poll: 18 for, 1 against, all other present abstain
Selection of 2005 venue
Got an attractive quote last year, trying to get more info
Lots of you would love to go back
Perhaps target it for 2006 for 10th anniversary
Direct flights from St. Maartens
(Stuart has a ridiculously well done powerpoint)
“It’s
like
Speak English, lovely, mountains,
Downsides: distant/expensive to get to, only 1 hotel
Hour ride from hotel to airport
Not as many lovely sandy beaches
Pluses: mountains, waterfalls, springs, scuba/snorkel, internet in room
Not a huge tourist place – cultural experience
Cheap rooms
Compare
to
Mountains vs. beaches, cheap & local vs. resort, bigger, sparser island
Some people in panama are setting up ecash for offshore gambling
Promoters were responsive, sound proposal
Conference would be at suburban resort/beach
Can’t speak about sponsorships or businesses, but hosts probably sponsor
Vote (would you go to FC in X)
Pure
preference based
Domonica: 18
Results of Election
2 blank
8 for Ari
17 for Ray
23 for Jean
Adjourned – Drink
Beer
Ari Juels – FC06 program if everything goes well
Breakfast in bed
Keynote: too much VC
Lunch with William Shatner
Financial Conundrum: why does market grow faster than the economy
A random beacon: a server that broadcasts verifiable unpredicactable numbers
Historical business analysis of ecash
Edith Elkin – How hard is it to manipulate voting
Model: n voters, m candidates, preference ordering
Manipulatability: want to adjust prefs based on how outcome looks
CMU: based on pre-round schemes
Can we make voting as hard as undoing 1-way functions
Yes & no
Shin’ichiro Matsuo – Preventing forward-dating requests on time-stamping protocol
Time-stamping protocols: simple signing or linking hash chain
Attack: forward-dating request
Easy to solve in simple case
BUT: collusion with time-stamp authority is stickier
Can solve, with no change to existing TSA, or
Roger Dingledine – Tor, Next-generation onion-routing
Mixnet is deployed, 19 nodes
Perfect forward secrecy
NO mixing, padding, traffic shaping
Does any of this work?
Congestion control
Simple rate limiting, have to keep internal nodes from attacks
Directory servers - How do I know who to choose?
Node needs to keep name and PK static
Exit policies - each person should control outgoing traffic (no spam)
E2E integrity – can an insider change messages en route
Rendez-vous points at a given node, so neither knows origin
Tor is TCP, multiplatform, not p2p, user-oriented
Nick Mathewson – Traffic Analysis is easy
High latency mixnets: mixmaster, etc
Some system that hides
Senders send to the same recipients over time, send more than once
Long term intersection attacks
If
No existing mixnet has n-squared padding or constant sending
Early results on a simple model
My results are based on simulations: hard to protect against
See this paper I submitted elsewhere
Goal: how long, in presence of bckgnd traffic, should type of sender be confident?
Makato Yokoo – Auction protocols without 3rd party services
Incentive-compatible protocols: vickrey auctions get true value
Spying is useless
Model w/out 3rd party (p2p)
Each player must help find winner
Incentive to throw out other bids
Goal: make my calculations irrelevant to my own winnings & payment
See rest of presentation on Wednesday
Rachel Greenstadt - Towards markets for personal information
Privacy problem
Potential Soln: property rights.
How viable technically?
Do you retain rights after sale?
Yes à need licenses, DRM
No à anonymize & aggregate,
Lesson from
Never challenged
Need a clear market structure
Rzulikar Ramzan – using quasimodo trees for cert revocation
(See his talk from Monday)
Cert revocation is annoying – have to
Use a hash chain – too long
Merkle trees have some issues
Rzulikar Ramzan – Eliminating random oracles in the Even-Mansour Cipher
Block cipher based on applying key before and after a random oracle function
Problem: proof that random oracle permutation applies to lesser conditions
Theorem: cipher is super pseudorandom
Extensions: can reduce key material
BUT: possible attack to recover key when known
Paul Syverson – Building NetMixes from MixNets
Synchronous batching: mix cascades beat free routes through mixnet
Cascade is a fixed route network of mixes
Relevant feature is that they’re symchonous
Comes from the research community, but decided to try to sell: Cyphermint
Cyphermint: software for secure financial transactions
Despite what we say, our mission has evolved
Traditional objectives: anonymity, transaction costs, secure acct-acct transfers
BUT: all wrong directions
Anonymity is fun, and a few people want it
BUT: consumers want more
Track down fraud
Support for lost/corrupted
Gov’t want to know about ‘suspicious’ behavior
In
the
Transaction costs being low are good
BUT: humans are more expensive than processors
Want ease of use, fraud detection, dispute resolution
Computer-computer accounts are important
BUT: money needs to enter & exit
Plan evolved over time
Need added value
V1.0 was about anonymity & superior security
BUT: people don’t really pay for security
People liked no charge-backs
V2.0 people who didn’t have computers, have access, banks
New market for ebusiness
Bricks & mortar store can sell things not in my store
V3.0 serve people without credit cards, bank accounts
Other financial services we can bring them as well!
New strategy: serving the unbanked with eshopping & financial services
Debit only
Helping the unbanked
The unbanked: 10-13% of US households have no bank acct, 35% have no CC
Outside US, these numbers are higher
Rapid increase in internet access usage among poor households
BUT – very little mobil commerce numbers
Financial services can be expensive, hard to obtain
Unbanked pay huge amount for fin services, can’t meet min balance
Q: How hard is it to open a savings account if you have cash?
A: Bad credit = hard to get checking, fees are high
Interface – kiosks & online
Can use kiosks to buy things, ask directions, and put money in for later
Some are ATMs, checks cashed, pay bills, transfer funds
NB: this is an interesting problem, and we’re putting PCs with cash online
Q: is there also a private network component?
A: Yes
Q: Can some one build a creative fake machine?
A: Our system won’t recognize it, so merchants won’t buy it; consumers duped
Q: How do you do check cashing?
A: Need prior registration, have a human-in-the-loop
Q: How do your prices compare to corner Checks-cashed places?
A: it’s a high risk, so we charge a comparable premium
Stored value card is integrated into internet system
Cards used at any V/MC term
Synergy: internet payments, kiosks, stored value
C: You know, the mike isn’t on. You don’t have to stand there.
A: All those years of yelling at students pays off
Design objectives
Privacy protection for end parties, but not to system
Flexible anonymity policies, tamper-proof
Range of payments, including micropayments
Scalability, currencies,
Paycash, driven by chaum’s electronic coins
Only payment system can create a coin, anyone can check
Centralized authorizer checks against double-spending
BUT: electronic coins don’t have tamper-proof records, so disputes can happen
Reciever signs a contract, sendor constructs and signs record w/ contract
Sender’s coin includes record, linked with keys
Can show that a coin has to have been used for that record alone
Can now have full check every transactions
Q: Do you need a key pair for every coin?
A: a key pair for every paybook of n coins
Summary: serving the unbanked, tamper proof, privacy but not nec. anonymity
Tech: integrate coins and transaction records
Status: accepted in FSU, kiosk systems in 7-11
Q: ATMs aren’t always online w/ your bank, but still authorize on faith
A: [from Simon] ATMs don’t do that, or else I’ll shut them down
Q: How do you deal with PATRIOT as it relates to acct registration
A: We follow it even if we may not have
to—register with info
Mechanism design – eliminate incentive to cheat
Design rules such that violating rules doesn’t increase utility
Like Vickrey auctions – spies don’t gain
Rational adversery does not become active adversary
No costs to make protocol verifiable, still safe if crypto is broken
Auction scheme – distributed Vickrey
Payment of a bidder is computed by all bidders except that bidder
What you calculate is irrelevant to what you get
Combinatorial auction for multiple goods
Vickrey auctions: 2nd price means that optimal strategy is to bid true value
Gen Vickrey Auct: payment computed from second price and combinatorial sum
GVA mechanism
Bidders compute others prices and publish it
Determining the price of any one bidder
Each bidder finds their allocation
Side payments cannot be enforced: no collusion unless strictly positive gain
Q: Can you have active attacks collusion against a single player?
A: we assume no externalities
Q: Can you use multiple identifiers to attack the system?
A: Currently under research
Trying to get a secure, robust system for a national lottery, increase business
Many lotteries/day, expensive to design & test machines for randomness
Pseudorandom bits can be used as much as you like
Design must be secure
Users can’t cheat, including insiders
Auditability for public confidence
System operation must be secure
Strict drawing times, many users, many draws
Users cannot in any way affect the number drawn
Components
6000 agencies w/ phone lines into lottery computer
Coupons in a coupon file
2 generators with verifiable audit mechanisms
Secure,
no leaking
Physical and network security, device security, display security
Operation requirements
Real uniform draw, with unpredictable results, or interference
Auditing: state & time stamping
Detection of all access, signed
Randomness
Traditional pseudorandom: uniform distribution, but predictable w/ limited # of states
Crypto-secure PNG – in principle can be guessed given initial state: det algs
Truly random number generators: depend on physical processes, hard to audit
Soln: combo of truly random and crypto-secure PNG
Internal verification that repeat process after production based on early commit.
NB: don’t have public verification
Need to prevent post-betting of picking the number after having seen winning number
Use hash value of all coupons in the number selection
Now can test by trying to regenerate winning number if we have a corrupted coupon file
Hash of coupons + truly random physical value à Naor-Reingold PNGà crypto à seed
Verifier takes values from each step, tries to duplicate
2 families of PNG, 4 generators overall: algebraic (BBS & RSA) & block cipher (DES & AES)
3 physical truly random devices, one clock phase & two HW
Testing
Apply constant online statistical tests of all generators
Cryptography is needed where randomness is of value
Basic tools useful, incorporate real world security too.
Vickrey auctions are great theoretically, but vulnerable to cheating auctioneer, require thought
Crypto takes into account security, but not cognitive thoughts
Individuals have preferences, should get something out of market participation
Design the mechanism to make honesty optimal
Participants don’t care about privacy, or want to harm others
Many participants with secret input that stays secret
Design criteria
Pareto-efficiency or revenue max
Resource effectiveness
Security against malicious auctioneer
Privacy
Minimal cognitive cost
Tradeoff with round-effectiveness: more time = better computation
Tradeoff with privacy: if I know others valuation, I can better compute own
New mechanism: multiple rounds
Only
highest m bids of every round is revealed
Rounds continue until 2nd highest price doesn’t change
Much lighter cognitive load
Trying to combine two different research approaches: crypto & game theory
Get neat features that simple layering doesn’t give you
Q: what kind of strategy should a malicious actor take? Can you guarantee pareto?
A: Yes.
Q: How big an m do you set?
A: as few as possible. Going from 2 to 3 doesn’t help privacy, need data about psych
<MISSING – Notes
from Guiseppe Ateniese
& Breno de Medeiros>
How to use crypto to solve a game theory Coordination problem:
Moderate benefits from cooperating, benefit from taking action, everyone lose if all act
Nash equil: one acts, the other doesn’t (2 equil)
But: Nash is not socially optimal—both have incentive to deviate from inaction
Game theory: correlated equilibrium
Trusted third party announces a probability dist
Tells each player what to play, but keep it secret
Equilibrium to always obey
Interesting question: what if you don’t trust the trusted party?
Already solved by Dodis, Halevi & Rabin, Crypto ‘00
Players run secure fn protocol to select actions
each player learns its action
Players play game, and coop is they don’t suspect the others
Minimize harms if they suspect à less total payoff
Blindable encryption
A chooses blinding factor for message X, sends cipher + blind to B
B decrypts X, but can’t learn X because of blinding fn, sends X back to A
Goal: choose a pair of actions from a list, PKs
A & B should be able to confidently choose their action
A blinds B’s action with 0
B gets own action, but not the correlated A action
Non-uniform distribution don’t work with D, H & R
They just say iterate until you have a uniform distribution
Suppose both players know non-uniform dist
B divides distribution into uniform blocks that contain either 1 or 2 actions
A chooses a random block, which comes with a probability
Blind decrypt from B
Get their own action
Efficient: bound by inverse of smallest prob. To assemble the blocks
Can solve correlated equilibrium w/ crypto, w/ non-uniform dist
Q: What about iterated game?
A: Model designed for a one-shot game
Motivation: discounts based on personal attributes
Standard solution: bob sends certificates to service provider
BUT: bob’s privacy
Goal: Bob should get credential that does not disclose
Multishow property: a coalition of service providers can’t correlate credentials to bob
Soln 1: Brand’s PKI
Can still have linkability, since while proof is different, cert is the same
Soln: Bob gets a bunch of certificates, uses a different one for each
Need lots of cert, for each service and each transaction
Soln 2: Camenish or Verheul
Bob converts the given cert into new, unique cert
BUT: others need more info to trust bob’s transformation
Soln: credential for each permission set
Too many credentials, for each service
Goal: one cert with unlinkability
RSArep problem, DLrep problem used
Given a Boolean formule, user knows given rep iff
System setup, each org publishes keys
Enrollment: user sends credential to org, sends back computer pair C, S
S is signature of G
User can compute S’ and G’ à multishow property
Bob can prove that S’ is valid
Usability – user can prove general statements over the credentials
Privacy
Non-tranferability: we can discourage bob from sharing his credential
Include private info he does not wish to share
Same computation time, but only need one cert from the authority
Q: can you revoke certificates?
A: Organization needs to publish list of credential revoked, user proves not on list
Same
problem of revoked sigs
C: Usability is part for security to make sure you’ve got enough credentials to hide in
How to pay wirelessly at the right counter
Problem: can end communicating with wrong cash register in crowded environment
Goal: short term pairing, but not authentication of identity
N physical nodes w/ human operators, broadcast network
Alice & Bob don’t share info a priori, channel can be authentic or private
Want to establish a shared secret over broadcast channel, but can’t send a lot
Can send many bits on broadcast, few bits on point to point
Similar to encrypted key exchange (EKE)
Samll password shared, want to exchange larger session key
Bob
generates session key, encrypts it with
Attacker only has one chance to use a dictionary attack, useless
Vulnerable to active attacks, but not offline passive attacks
Ephemeral key exchange problem depends on channel
Authentic,
private channel à
Private channel protects password, authentic protects against direct attack
Private, nonauthentic password
Alice & Bob send each other a password, XOR it together
Now we have a shared password à EKE
Open, unauthenticated channel requires 4 phases: want a key exchange
Commit: broadcast hash of random numbers
Authenticate: Gets a short authentic hash over point to point
Key exchange: Can correlate two hashes to procede
Exchange keys over broadcast
Key validation
Performance: passive attacker
Probability of active attacker is bound by guessing hash from the two exchanges (low)
Implementation Need the low bandwidth private channel
Brief physical contact, aiming a mobile, data entry
Future work: unidirectional channel, anonymous broadcast networks, weaker assumptions
Q: Unidirectional channel just for side channel?
A: Yes.
C: Combining low bandwidth w/ broadcast is like a phone w/ RFID.
Q: Existing key exchange protocols aren’t sufficient?
A: EKE is good for a few cases, but interesting bit is the non-private channel
These notes were recorded on the fly by Allan Friedman, and any omissions or inaccuracies are purely his fault. To learn more about the papers here, please see the proceedings (to be published by Spring-Verlag) the IFCA website, or contact the authors directly.
I apologize for the horrendous formatting; I took notes on a
windows box and was lazy about dumping into HTML, so plenty of nasty artifacts
remain.