Distributed Transactions and Security

1
Distributed Transactions and Security

• Zachary G. Ives
• University of Pennsylvania
• CIS 455 / 555 Internet and Web Systems
• April 16, 2009

2
Recall Lock-Based Concurrency Control

• Strict Two-phase Locking (Strict 2PL) Protocol
• Each transaction must obtain
• a S (shared) lock on object before reading
• an X (exclusive) lock on object before writing
• An owner of an S lock can upgrade it to X if no
  one else is holding the lock
• All locks held by a transaction are released when
  the transaction completes
• Locks are handled in a growing phase, then a
  shrinking phase
• (Non-strict) 2PL Variant Release locks anytime,
  but cannot acquire locks after releasing any lock.

3
Aborting a Transaction Strict vs. Non-Strict

• If a transaction Ti is aborted, all its actions
  have to be undone
• Not only that, if Tj reads an object last written
  by Ti, Tj must be aborted as well!
• This happens when we have non-strict 2PL
• Most systems avoid such cascading aborts by
  releasing a transactions locks only at commit
  time (strict 2PL)
• If Ti writes an object, Tj can read this only
  after Ti commits
• Actions are undone by consulting the transaction
  log

4
From Distributed Commits toDistributed
Concurrency Control

• What we saw were the steps involved in preserving
  atomicity and consistency in a distributed
  fashion
• Lets briefly look at distributed isolation
  (locking)

5
Distributed Locking

• How do we manage locks across many sites?
• Centralized One site does all locking
• Vulnerable to single site failure
• Primary Copy All locking for an object done at
  the primary copy site for this object
• Reading requires access to locking site as well
  as site where the object is stored
• Example of this today Yahoo uses Primary Copy
  locking in their distributed storage (different
  owner for each object)
• Fully Distributed Locking for a copy done at
  site where the copy is stored
• Locks at all sites holding the object being
  written

6
A Danger with Locks Deadlocks

• Deadlock Cycle of transactions waiting for locks
  to be released by each other
• Two ways of dealing with deadlocks
• Deadlock prevention
• Deadlock detection

7
Deadlock Prevention

• Assign priorities based on timestamps (older
  higher)
• Assume Ti wants a lock that Tj holds
• Do one of
• Wait-Die If Ti has higher priority, Ti waits for
  Tj otherwise Ti aborts
• Wound-wait If Ti has higher priority, Tj aborts
  otherwise Ti waits
• Higher-priority transactions never wait for
  lower-priority
• If a transaction re-starts, make sure it has its
  original timestamp
• Keeps it from always getting aborted!

8
Distributed Deadlock Detection

• Each site maintains a local waits-for graph
• A global deadlock might exist even if the local
  graphs contain no cycles

T1
T1
T1
T2
T2
T2
SITE A
SITE B
GLOBAL

• Three solutions
• Centralized (send all local graphs to one site)
• Hierarchical (organize sites into a hierarchy and
  send local graphs to parent in the hierarchy)
• Timeout (abort transaction if it waits too long)

9
Summary of Transactions and Concurrency

• There are many (especially monetary) transfers
  that need atomicity and isolation
• Transactions and concurrency control provide
  these features
• In a distributed, 3-tier setting they run in an
  Application Server
• Similar features are provided in a 2-tier setting
  for applications that run directly in the DBMS
• Two-phase locking ensures isolation
• Two-phase commit is a voting scheme for doing
  distributed commit

10
Distributed Security and E-Commerce

• Transactions make sure things happen when we want
  them to
• Security makes sure things dont happen when we
  dont want them to!
• Lets look at some essentials of security in
  distributed environments

11
Basic Terminology

• Authorization determines mode of access allowed
• Common solutions access control lists,
  capabilities,
• We previously discussed how views could be used
  to define authorization levels
• Authentication means of verifying identity
• Common cases password/UID, PIN, fingerprint,
  demonstration of ability to encrypt with private
  key, etc.
• Encryption used to protect data
• A common notation, used in the chapter from
  Lewis/Bernstein/Kifer that appears in your
  reader
• ciphertext Ksenderplaintext
• plaintext KreceiverKsenderplaintext
• Lets look at encryption in detail

12
Authorization (Access Control)

• Capabilities
• Special, hard-to-forge handles or pointers to
  objects/services
• Independent of authentication of who a user is
• Possessing a capability ? you can use the
  service/object
• e.g., pass-phrase SHA-1 key private key etc.
• Capabilities are easy to pass on to others, but
  hard to revoke
• Access Control Lists (ACLs)
• During each access to an object/service,
  authorization is checked against a list
• Usually a notion of different groups, rights
• e.g., Unix or Windows file system most databases
• Easy to revoke rights hard to pass them on
• Requires a scheme for authenticating a user

Most commonapproachtoday
13
Granularity What to Control

• In a file system, ACLs are checked at the
  granularity of an open, a read, a write, etc. to
  a whole file
• Analogous process holds HTTP server, when we
  protect directories, files
• This is great for large, atomic units, e.g.,
  images
• But sometimes we need finer-grained detail
• If exporting XML, we may want to expose different
  data to marketing than we do order fulfillment
• Add access control lists over views of the data

14
Hypothetical View-BasedProtection Example

• define function MarketingView() returns
  purchase for p in doc(purchases.xml)/purcha
  ses/purchase where p/date() gt fntodays-date()
  fndateInterval(0,1,0) return ltpurchasegt
  p/isbn p/addr/state
  lt/purchasegtdefine function OrderFulfillmentView
  () returns purchase for p in
  doc(purchases.xml)/purchases/purchase return
  pgrant permission read on MarketingView to
  MarketerGroupgrant permission read on
  OrderFulfillmentView to WarehouseGroup

These arent yet present in XQuery, but they are
in SQL
15
View-Based Security

• Views restrict attributes and values that are
  visible
• Thus restricting the queries that can be posed
• Much more powerful than simply restricting
  documents
• Caveat not always enough to guarantee security
  sometimes information is inadvertently leaked
• Might correlate info from multiple tables with
  different attributes
• Might know, e.g., that theres only one customer
  in a given state
• OK, so how do we enforce that data isnt actually
  seen by eavesdroppers, even if the user has
  permission?
• Lets look at some attacks

16
Authentication, Encryption, and Security

• We now know how to specify who has what rights to
  data
• How do we ensure
• We know who were talking to, so we give them the
  right permissions?
• Nobody can eavesdrop on our communication and
  steal our data?

17
Message-Dropping Attacks

• Can happen if someone manages to get between us
  and whomever were conversing with
• How might this happen?
• By and large, our protocols are resilient to
  occasional dropped messages
• Not much happens without acknowledgement we
  frequently time out

C
S
order
confirm?
C
S
18
Replay Attacks

• A very simple attack
• Intruder doesnt need to understand or alter the
  contents of a message just send it multiple
  times
• Can be all at once, or can play the message again
  a week later

buy 5 copies
buy 5 copies
C
S
I
19
Message Forging Attacks

• Generally more difficult than the first two
  classes
• Needs the ability to modify messages from the
  sender

buy 5000 copies,ship to Hawaii
buy 5 copies
C
S
I
20
Man in the Middle Attacks

• The intruder impersonates both the client and the
  sender
• Sometimes, this is by IP spoofing pretending
  that packets originate from a different host
• Intruder can masquerade as the client from then on

Hi, amazon.com, my password is 1234
Hi, amazon.com, my password is 1234
C
S
I
andId like to buy a red MazdaMiata
Welcome toamazon.com
amazon.com
schuylkill.com
21
Distributed Security

• Generally, were going to
• Try to ensure that messages cant be replayed
• Try to ensure that messages are unforgeable
• See if we can avoid most man-in-the-middle attacks

22
Encryption/Decryption
Illustration from Lewis/Bernstein/Kifer
23
Symmetric Cryptography

• Uses the same key for encryption and decryption
• Aka secret key crytography
• Block cipher block of text ? ciphertext block
• Substitution cipher simple substitutions of
  char(s) for char(s)
• Transposition cipher reorder the chars in the
  block
• DES (Data Encryption Standard) only 56b key
• Sequence of stages that encrypt one anothers
  output
• Makes it less vulnerable to frequency analysis
  attack
• Non-block cipher
• Bitstream cipher
• XORs plaintext with pseudo-random numbers
  generated when key is used as seed value
• What if the random number generator isnt very
  random?

24
Asymmetric Encryption

• This is public/private-key encryption (public key
  cryptography)
• Here
• M KCpriv KCpub M
• For two-way communication, use a second key-pair
• (Often public key algorithm is commutative,
  though)
• First proposed public-key encryption scheme was
  Diffie-Hellman 76
• But we generally use RSA

25
RSA Algorithm

• Create two large, e.g. 1024b, relatively prime
  numbers, p and qChoose decryption int. d
  relatively prime to (p - 1)(q - 1)Choose
  encryption int. e so gcd(e, d) 1 (commonly 3,
  17, or 65537)
• Break message into blocks, M, treated as ints
  from 0 to pq 1Encryption key (e,
  pq)Decryption key (d, pq)
• To encrypt, C Me (mod pq)
• To decrypt, M Cd (mod pq)
• Works because M (Me (mod pq))d (mod pq) due to
  elementary number theory
• Relies on fact that factoring pq is (believed to
  be) expensive

26
Digital Signatures -- I/II

• Frequently, we need to sign a message to verify
  it came from us (or our server)
• Can use asymmetric cryptography if M KCpub
  KCpriv M
• Encrypt message with private key validate with
  public key
• (Obviously, others need to get the public key)

27
Digital Signatures II/II

• Less costly message digests
• Compute a one-way hash, f(M) , with these
  properties
• All values in fs range are equally likely
• Unlikely that we can find M where f(M) f(M)
  because large number of Ms map to same region
• If any bit of the message is changed, every bit
  in f(M) has a 50 chance of changing
• f(M), f(M) arent same simply because M, M are
  similar
• Encrypt this, KCprivf(M) and send with M
• Just given this, what attacks might be possible?

28
Nonces Prevent Replay Attacks

• To prevent replay attacks, we need to ensure that
  a message would be different each time its sent,
  and we keep track of what weve already seen
• A nonce is a special bit string thats difficult
  to forge but easy to authenticate
• Commonly, the client or server will pick some
  value N and encrypt it
• Responses will return N1 (encrypted), etc.
• Frequently, the initial N is a timestamp or
  message counter
• A form of a nonce called salt is often added not
  for authentication, but to make it harder to
  guess the message content

29
Key Distribution

• Whether public or secret key cryptography is
  used, must be able to tell who were talking
  with
• Need to negotiate a session key (Kerberos)
• or need to get a public key (SSL)
• Why is authentication critical?

30
The Kerberos Protocol (from MIT)

• Used commonly to authenticate to a server
• Relies on a trusted third party, a Key
  Distribution Server
• Users and servers have kerberos authentication
  keys, KC,KDS, KS,KDS, used to authenticate with
  the KDS
• The KDS creates a session key and distributes it
  in a ticket thats used for conversing with the
  server S
• Can also provide single sign-on one
  authentication thats shared across machines
• Give a ticket-granting ticket that is used to
  talk with a ticket-granting server in a way
  thats similar

31
Tickets and Kerberos
KC,KSKsess, S, TTL
names of C, S in cleartext
KS,KSKsess, C, TTL
KC,KS f(PC)
KsessC, time
Illustration from Lewis/Bernstein/Kifer
32
E-Commerce

• Clearly, one of the biggest uses of
  authentication on the Web today
• B2B can often negotiate secret keys between
  pairs
• Selling to consumer (B2C/C2B) often requires
  several levels of authorization and
  authentication
• Want to authenticate the user
• Want to authenticate the credit card company
  server
• Want to check for user authorization to purchase
• And obviously, want to prevent eavesdropping
  and replay!

33
Secure Sockets Layer (SSL)

• Like Kerberos, relies on a trusted third party
• Certificate authority (CA) issues certificates to
  certify a server and its public key
• Verisign is perhaps the best known of these
• A server S generates public-private keypair
• Sends the public key, other info (plus ) to
  Verisign (etc.)
• Gets back a certificate with
• CA name
• Ss name, URL, public key
• Timestamp and expiration info

34
Example Certificate

• Owner CNGTE CyberTrust Root, OGTE
  Corporation, CUSIssuer CNGTE CyberTrust
  Root, OGTE Corporation, CUSSerial number
  1a3Valid from Fri Feb 23 230100 GMT 1996
  until Thu Feb 23 235900 GMT 2006Certificate
  fingerprintsMD5 C4D7F0B2A3C57D6167F00
  4CD43D3BA58SHA1 90DEDE9E4C4E9F6FD8
  8617579DD391BC65A68964

35
The SSL Protocol

• Client C connects to server S from enterprise E
• S sends Es certificate (cleartext)
• C validates the certificate using the CA (e.g.,
  Verisign)s public key
• C generates and sends to S a session key
  encrypted with Es public key
• Java has built-in support for SSL (Java Secure
  Socket Extension, integrated in 1.4) and a tool
  for managing certificates (keytool)

36
So

• The client and server know each other given SSL
• How do we go ahead and make a purchase?
• Most commonly you enter your credit card number
• Sometimes this is stored in the retailers system
  for future purposes!
• Best case
• The CC info is stored in a special, firewalled
  server, not part of the web site
• Web server has other account info about you
• When a transaction goes through, web site sends
  order to this special server, which combines it
  with CC info and sends it onward
• But often its not quite so secure!
• Protocols have been proposed (e.g., SET from
  VISA) that dont use credit card info but not
  really adopted