Bitcoin is a decentralized payment system that relies on Proof-of-Work (PoW) to verify payments. Nowadays, Bitcoin is increasingly used in a number of fast payment scenarios, where the time between the exchange of currency and goods is short (in the order of few seconds). While the Bitcoin payment verification scheme is designed to prevent double-spending, our results show that the system requires tens of minutes to verify a transaction and is therefore inappropriate for fast payments. An example of this use of Bitcoin was recently reported in the media: Bitcoins were used as a form of \emph{fast} payment in a local fast-food restaurant. Until now, the security of fast Bitcoin payments has not been studied. In this paper, we analyze the security of using Bitcoin for fast payments. We show that, unless appropriate detection techniques are integrated in the current Bitcoin implementation, double-spending attacks on fast payments succeed with overwhelming probability and can be mounted at low cost. We further show that the measures recommended by Bitcoin developers for the use of Bitcoin in fast payments are not always effective in detecting double-spending; we show that if those recommendations are integrated in future Bitcoin implementations, double-spending attacks on Bitcoin will still be possible. Finally, we propose and implement a modification to the existing Bitcoin implementation that ensures the detection of double-spending attacks against fast payments.

Double-spending fast payments in bitcoin

As organizations increase their reliance on, possibly distributed, information systems for daily business, they become more vulnerable to security breaches even as they gain productivity and efficiency advantages. Though a number of techniques, such as encryption and electronic signatures, are currently available to protect data when transmitted across sites, a truly comprehensive approach for data protection must also include mechanisms for enforcing access control policies based on data contents, subject qualifications and characteristics, and other relevant contextual information, such as time. It is well understood today that the semantics of data must be taken into account in order to specify effective access control policies. Also, techniques for data integrity and availability specifically tailored to database systems must be adopted. In this respect, over the years, the database security community has developed a number of different techniques and approaches to assure data confidentiality, integrity, and availability. However, despite such advances, the database security area faces several new challenges. Factors such as the evolution of security concerns, the "disintermediation" of access to data, new computing paradigms and applications, such as grid-based computing and on-demand business, have introduced both new security requirements and new contexts in which to apply and possibly extend current approaches. In this paper, we first survey the most relevant concepts underlying the notion of database security and summarize the most well-known techniques. We focus on access control systems, on which a large body of research has been devoted, and describe the key access control models, namely, the discretionary and mandatory access control models, and the role-based access control (RBAC) model. We also discuss security for advanced data management systems, and cover topics such as access control for XML. We then discuss current challenges for database security and some preliminary approaches that address some of these challenges.

/pdf/database-security-concepts-approaches-and-challenges-3efa6njiby.pdf

Database security - concepts, approaches, and challenges

Mobile devices enable secure, convenient authorization of e-banking, retail payment, brokerage, and other types of transactions.

Payments and banking with mobile personal devices

An automated retail terminal in which a plurality of goods and/or services are provided in an integrated system The integrated system generally avoids duplicating hardware or functions in the course of delivering the goods or services offered, so for example in a combination ATM and Internet kiosk the same credit card or smart card reader is used for both the ATM and the Internet kiosk functions, the same control screen activates the ATM functions and the Internet functions, and etc

Automated transaction machine

The World Wide Web Consortium's Platform for Privacy Preferences (P3P) lets Web sites convey their privacy policies in a computer-readable format. Although not yet widely adopted, P3P promises to make Web site privacy policies more accessible to users.

P3P: making privacy policies more useful

This paper discusses the design, implementation, and deployment of a secure and practical payment system for electronic commerce on the Internet. The system is based on the iKP family of protocols-(i=1,2,3)-developed at IBM Research. The protocols implement credit card-based transactions between buyers and merchants while the existing financial network is used for payment clearing and authorization. The protocols are extensible and can be readily applied to other account-based payment models, such as debit cards. They are based on careful and minimal use of public-key cryptography, and can be implemented in either software or hardware. Individual protocols differ in both complexity and degree of security. In addition to being both a precursor and a direct ancestor of the well-known SET standard, iKP-based payment systems have been in continuous operation on the Internet since mid-1996. This longevity-as well as the security and relative simplicity of the underlying mechanisms-makes the iKP experience unique. For this reason, this paper also reports on, and addresses, a number of practical issues arising in the course of implementation and real-world deployment of a secure payment system.

/pdf/design-implementation-and-deployment-of-the-ikp-secure-66apzafbns.pdf

Design, implementation, and deployment of the iKP secure electronic payment system

Enterprises advertise privacy promises using the W3C Platform for Privacy Preferences (P3P). These privacy promises define what recipients can obtain what collected data for what purpose. Internally, enterprises can use fine-grained privacy practices such as defined by the Platform for Enterprise Privacy Practices (E-P3P) to enforce privacy. These internal privacy policies should guarantee and enforce the promises made to the customers. Since privacy practices reflect business internals, they can change frequently. As a consequence, it can be challenging to keep the promises up-to-date with the actual practices. To enable up-to-date privacy promises, we describe a methodology for enterprises to promise what they can keep. This is done by automatically transforming E-P3P privacy practices into corresponding P3P privacy promises that reflect the actual enterprise-internal behavior. These P3P promises can then be published on a regular basis. Whenever the internal policies change, the P3P promises can easily be updated as well.

Translating privacy practices into privacy promises - how to promise what you can keep

XACML is commonly used as a policy exchange mechanism, decision engines are available, and verification tools are under development. However, no support for legacy access control systems exists yet. To explore the feasibility to support legacy systems, we designed and implemented a mapping of the IBMreg Tivolireg Access Manager policy language into XACML. Although the Tivoli Access Manager policy language, being ACL-based, is simpler in general, it turned out to be a non-trivial task to encode the interplay of the Tivoli Access Manager policy elements and decision logic within XACML. To achieve this task, we had to come up with a novel use of XACML features.

Implementing ACL-Based Policies in XACML

The Platform for Privacy Preferences (P3P) can be a viable tool for organizations to clarify their privacy promises. In this paper, we summarize our experiences and describe some of the problems we have encountered when using P3P. Our main criticisms on P3P are its complicated structure, ambiguities in the specification, and missing guidelines for user agents. We suggest several improvements such as an extended but simplified syntax and a revised consent model that groups opt-in/opt-out choices into one "consent block", which can be associated with multiple statements.

E. Van Herreweghen

Papers

Design, implementation, and deployment of the iKP secure electronic payment system

Translating privacy practices into privacy promises - how to promise what you can keep

Implementing ACL-Based Policies in XACML

Amending P3P for clearer privacy promises