Petter Reinholdtsen: Entries Tagged usenix

+ A fist full of non-anonymous Bitcoins +

+ 29th January 2014 +

Bitcoin is a incredible use of peer to peer communication and +encryption, allowing direct and immediate money transfer without any +central control. It is sometimes claimed to be ideal for illegal +activity, which I believe is quite a long way from the truth. At least +I would not conduct illegal money transfers using a system where the +details of every transaction are kept forever. This point is +investigated in +USENIX ;login: +from December 2013, in the article +"A +Fistful of Bitcoins - Characterizing Payments Among Men with No +Names" by Sarah Meiklejohn, Marjori Pomarole,Grant Jordan, Kirill +Levchenko, Damon McCoy, Geoffrey M. Voelker, and Stefan Savage. They +analyse the transaction log in the Bitcoin system, using it to find +addresses belong to individuals and organisations and follow the flow +of money from both Bitcoin theft and trades on Silk Road to where the +money end up. This is how they wrap up their article:

+ +

+
"To demonstrate the usefulness of this type of analysis, we turned +our attention to criminal activity. In the Bitcoin economy, criminal +activity can appear in a number of forms, such as dealing drugs on +Silk Road or simply stealing someone elseâs bitcoins. We followed the +flow of bitcoins out of Silk Road (in particular, from one notorious +address) and from a number of highly publicized thefts to see whether +we could track the bitcoins to known services. Although some of the +thieves attempted to use sophisticated mixing techniques (or possibly +mix services) to obscure the flow of bitcoins, for the most part +tracking the bitcoins was quite straightforward, and we ultimately saw +large quantities of bitcoins flow to a variety of exchanges directly +from the point of theft (or the withdrawal from Silk Road).
+ +
As acknowledged above, following stolen bitcoins to the point at +which they are deposited into an exchange does not in itself identify +the thief; however, it does enable further de-anonymization in the +case in which certain agencies can determine (through, for example, +subpoena power) the real-world owner of the account into which the +stolen bitcoins were deposited. Because such exchanges seem to serve +as chokepoints into and out of the Bitcoin economy (i.e., there are +few alternative ways to cash out), we conclude that using Bitcoin for +money laundering or other illicit purposes does not (at least at +present) seem to be particularly attractive."
+

+ +

These researches are not the first to analyse the Bitcoin +transaction log. The 2011 paper +"An Analysis of Anonymity in +the Bitcoin System" by Fergal Reid and Martin Harrigan is +summarized like this:

+ +

+"Anonymity in Bitcoin, a peer-to-peer electronic currency system, is a +complicated issue. Within the system, users are identified by +public-keys only. An attacker wishing to de-anonymize its users will +attempt to construct the one-to-many mapping between users and +public-keys and associate information external to the system with the +users. Bitcoin tries to prevent this attack by storing the mapping of +a user to his or her public-keys on that user's node only and by +allowing each user to generate as many public-keys as required. In +this chapter we consider the topological structure of two networks +derived from Bitcoin's public transaction history. We show that the +two networks have a non-trivial topological structure, provide +complementary views of the Bitcoin system and have implications for +anonymity. We combine these structures with external information and +techniques such as context discovery and flow analysis to investigate +an alleged theft of Bitcoins, which, at the time of the theft, had a +market value of approximately half a million U.S. dollars." +

+ +

I hope these references can help kill the urban myth that Bitcoin +is anonymous. It isn't really a good fit for illegal activites. Use +cash if you need to stay anonymous, at least until regular DNA +sampling of notes and coins become the norm. :)

+ +

As usual, if you use Bitcoin and want to show your support of my +activities, please send Bitcoin donations to my address +15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

+ +

+ + + Tags: bitcoin, english, personvern, sikkerhet, usenix. + + +

+ 12 years of outages - summarised by Stuart Kendrick +

+ 26th October 2012 +

I work at the University of Oslo +looking after the computers, mostly on the unix side, but in general +all over the place. I am also a member (and currently leader) of +the NUUG association, which in turn +make me a member of USENIX. NUUG +is an member organisation for us in Norway interested in free +software, open standards and unix like operating systems, and USENIX +is a US based member organisation with similar targets. And thanks to +these memberships, I get all issues of the great USENIX magazine +;login: in the +mail several times a year. The magazine is great, and I read most of +it every time.

+ +

In the last issue of the USENIX magazine ;login:, there is an +article by Stuart Kendrick from +Fred Hutchinson Cancer Research Center titled +"What +Takes Us Down" (longer version also +available +from his own site), where he report what he found when he +processed the outage reports (both planned and unplanned) from the +last twelve years and classified them according to cause, time of day, +etc etc. The article is a good read to get some empirical data on +what kind of problems affect a data centre, but what really inspired +me was the kind of reporting they had put in place since 2000.

+ +

The centre set up a mailing list, and started to send fairly +standardised messages to this list when a outage was planned or when +it already occurred, to announce the plan and get feedback on the +assumtions on scope and user impact. Here is the two example from the +article: First the unplanned outage: + +

+Subject:     Exchange 2003 Cluster Issues
+Severity:    Critical (Unplanned)
+Start: 	     Monday, May 7, 2012, 11:58
+End: 	     Monday, May 7, 2012, 12:38
+Duration:    40 minutes
+Scope:	     Exchange 2003
+Description: The HTTPS service on the Exchange cluster crashed, triggering
+             a cluster failover.
+
+User Impact: During this period, all Exchange users were unable to
+             access e-mail. Zimbra users were unaffected.
+Technician:  [xxx]
+

+ +Next the planned outage: + +

+Subject:     H Building Switch Upgrades
+Severity:    Major (Planned)
+Start:	     Saturday, June 16, 2012, 06:00
+End:	     Saturday, June 16, 2012, 16:00
+Duration:    10 hours
+Scope:	     H2 Transport
+Description: Currently, Catalyst 4006s provide 10/100 Ethernet to end-
+	     stations. We will replace these with newer Catalyst
+	     4510s.
+User Impact: All users on H2 will be isolated from the network during
+     	     this work. Afterward, they will have gigabit
+     	     connectivity.
+Technician:  [xxx]
+

+ +

He notes in his article that the date formats and other fields have +been a bit too free form to make it easy to automatically process them +into a database for further analysis, and I would have used ISO 8601 +dates myself to make it easier to process (in other words I would ask +people to write '2012-06-16 06:00 +0000' instead of the start time +format listed above). There are also other issues with the format +that could be improved, read the article for the details.

+ +

I find the idea of standardising outage messages seem to be such a +good idea that I would like to get it implemented here at the +university too. We do register +planned +changes and outages in a calendar, and report the to a mailing +list, but we do not do so in a structured format and there is not a +report to the same location for unplanned outages. Perhaps something +for other sites to consider too?

+ +

+ + + Tags: english, nuug, standard, usenix. + + +

+ Petter Reinholdtsen + +

Entries tagged "usenix".

Archive

Tags