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 [EMAIL PROTECTED]
