Interesting bit of a quote

[Anne & Lynn Wheeler]

Anton Stiglic wrote:
> Does that mean that you (the company) are safe if all of the personal
> information in the database is simply encrypted with the decryption key
> laying right there alongside the data?  Alot of solutions do this, some go
> to different lengths in trying to obfuscate the key.

note that a lot of the data breaches and financial fraud have involved 
things with payment card transactions ... where details of previous 
transactions is sufficient for crook to perform fraudulent transactions 
(and as a result one of the reasons that there is various concern of 
data breaches involving files containing payment card data).

also a lot of the identity theft incidents involve "account fraud", i.e. 
being able to perform a fraudulent transaction against an existing 
account with the use of minimal amount of harvested information
http://www.garlic.com/~lynn/subpubkey.html#harvest

there has been some attempt by the FTC and other organizations to 
differentiate account fraud from other forms of identity theft.

however, the information in the transactions is also required in dozens 
of business processes. this somewhat led to my old post on security 
proportional to risk
http://www.garlic.com/~lynn/2001h.html#61

and my frequent observation that the planet could be buried under miles 
of crypto and still not be able to stop the information leakage .... 
i.e. transaction details having diametrically opposed requirements ... 
openly available for all sorts of business processes and never divulged 
because it can lead to fraudulent transactions.

in the mid-90s, the x9a10 working group had been given the requirement 
to preserve the integrity of the financial infrastructure for all retail 
payments. the result was x9.59 financial industry retail payment standard
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

one of the features of x9.59 standard was that it eliminated the leakage 
of transaction information as a financial fraud vulnerability (i.e. a 
crook could not perform a fraudulent transaction just from information 
from previous transaction or skimming).

as a result the integrity of the financial infrastructure and x9.59 
transactions are preseved for both transactions "in-flight" (say over 
the internet) as well as transactions "at-rest" (in databases and 
transaction logs), w/o having to resort to "hiding" the transactions 
with technology like cryptography.

a thread/discussions about "naked transactions" and their 
vulnerabilities (i.e. unarmored, non-x9.59 transactions):
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all 
go naked
http://www.garlic.com/~lynn/aadsm24.htm#8 Microsoft - will they bungle 
the security game?
http://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all 
go naked
http://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all 
go naked
http://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK 
Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#31 DDA cards may address the UK 
Chip&Pin woes

series of blogs on "naked" payment (transaction) issue:
https://financialcryptography.com/mt/archives/000745.html
https://financialcryptography.com/mt/archives/000744.html
https://financialcryptography.com/mt/archives/000747.html
https://financialcryptography.com/mt/archives/000749.html

misc. past posts mentioning "at rest" and "in flight" transaction 
vulnerabilities
http://www.garlic.com/~lynn/2000g.html#33 does CA need the proof of 
acceptance of key binding ?
http://www.garlic.com/~lynn/2001c.html#76 Unix hard links
http://www.garlic.com/~lynn/2002d.html#39 PKI Implementation
http://www.garlic.com/~lynn/2002f.html#9 PKI / CA -- Public Key & 
Private Key
http://www.garlic.com/~lynn/2002f.html#35 Security and e-commerce
http://www.garlic.com/~lynn/2002j.html#14 Symmetric-Key Credit Card 
Protocol on Web Site
http://www.garlic.com/~lynn/2002n.html#14 So how does it work... 
(public/private key)
http://www.garlic.com/~lynn/2002p.html#50 Cirtificate Authorities 'CAs', 
how curruptable are they to
http://www.garlic.com/~lynn/2003b.html#41 Public key encryption
http://www.garlic.com/~lynn/2003d.html#30 SSL questions
http://www.garlic.com/~lynn/2003j.html#53 public key confusion
http://www.garlic.com/~lynn/2003m.html#38 Questioning risks of using the 
same key for authentication and encryption
http://www.garlic.com/~lynn/2004c.html#35 Computer-oriented license plates
http://www.garlic.com/~lynn/2004f.html#30 vm
http://www.garlic.com/~lynn/2005d.html#25 The future of the Mainframe
http://www.garlic.com/~lynn/2005g.html#51 Security via hardware?
http://www.garlic.com/~lynn/2005i.html#1 Brit banks introduce delays on 
interbank xfers due to phishing boom
http://www.garlic.com/~lynn/2005n.html#24 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005t.html#34 RSA SecurID product
http://www.garlic.com/~lynn/2006k.html#17 Hey! Keep Your Hands Out Of My 
Abstraction Layer!

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com