Video - Michael Perklin-C4 Certification, DevCore Draper University

Crypto Currency Certification Consortium. Non Profit Organization. Establishes and Maintains standards for Cryptocurrency. Works with leading experts to build best practices. Publishes all standards openly for the world to adopt. Administers certifications to both businesses and personnel.

Provides: Clear security guidance for companies, clear measurement criteria for auditors, more secure crypto currency eco-system for us all, free and open for everyone to use.Security isn't just tech, secure hardware and software is important, so are policies, procedures, and trained personnel. Michael Perklin is Director of Bitcoin Alliance of Canada, President of C4, President of Bitcoinsultants, Cyber Security Expert, Public Speaker, and Geek.

TRANSCRIPT

BRUCE FENTON: All right. Next folks, we’re going to break for lunch right after this we have Andreas and Michael coming up. One quick thing I’ll mention on a more serious note is as I mentioned at the opening one of the big things that’s needed in this space is more understanding about what is going on in development.

So, what we need – there’s an initiative that we’re working with Bitcoin foundation to get that knowledge out there and we need two things. We need people with deep technical understanding and we need people with great communication skills and we’ve got to bridge those things. So if you are either, which hopefully should be everyone, let me know if you’d like to volunteer. What it would be basically – and there’s a role for everyone.

Even if you’re not super technical maybe you want to just learn that can actually be very useful because somebody who’s not technical sitting and listening to developer meetings going on (0:01:02) going into their discussion groups that actually can be very useful because I can well, I don’t understand this so let me figure it out in a way that I can understand and you can partner with somebody who’s more technical and say okay, here’s what I meant by that who may not have the time to communicate it or may not have as good a communication skills.

So that’s something that we’re doing if you’re – if you have either of those skills or want to be we’re going to try and get as high level technical expertise as we can get and make it as simple and accessible as possible because as this industry grows there are people, I mean there are people that have huge venture capital funding who don’t really understand what’s going on in development. There are a lot of people being involved in this space and that’s okay by the way.

We need people of all different skill levels. I always recommend that if you are Wozniak find your Steve jobs. There are different skills that are needed and some of those skill have nothing to do with development in this industry. So, that’s an initiative that we’re working on that I think is very important and a great role for us.

So, our next speakers are Michael Perklin and Andreas Antonopoulos. Andreas is somebody that a lot of people, you know, sort of introduced a lot of people to Bitcoin. I’m sure probably – is there anybody who hasn’t seen Andreas’ videos or know who Andreas is? Okay. There’s probably two but they’re like, I don’t know (0:02:21) and Michael is the leader of C4 which is the certification program that I mentioned earlier so we’re really excited to have them. Here we go, Michael and Andreas.

MICHAEL PERKLIN: Thanks for the introduction, Bruce. Really appreciate that. (0:02:46) two seconds while I throw some visuals up on this nice and dim screen.

All right. So, we’re going to be giving a workshop to day about the cryptocurrency security standard. It’s something that’s been in the works now for quite a few months and it’s very relevant to all of the work that you will be doing with Bitcoin or cryptocurrencies as you move forward. But before we start with the CCSS quick note about C4.

So, C4 is a non-profit organization. It’s a cryptocurrency certification consortium. We are a standards body in the cryptocurrency space. You can think of us sort of like the ISO of cryptocurrencies. We work leading experts together all the best practices, we put them all together into documents that are easy for everyone to follow and we publish them openly to make your jobs easier.

With all these different hacks being announced all over the place Bitcoin has an image problem and one of the goals that C4 was put together for is to address this image problem. And quick aside this actually started with a short conversation that I had with Gavin Andresen the day that he announced the Bitcoin foundation. I was under the impression that the Bitcoin foundation was going to be creating all these best practices and standards. When I spoke with Gavin he corrected that impression and said, “Well no, actually we’re going to be doing this, this and this’ but why didn’t you do that. If you see something in the space that needs to be done just do it.

So we pulled – Wow, that’s one little fast. We pulled together a few people from a variety of different cryptocurrency spaces. Myself, Joshua McDougal, Vitalik Buterin from Ethereum, Pamela Morgan and of course Andreas and we pulled together this (0:04:41) as well as (0:04:42) from many other people in the space to develop this standards and certifications.

So, as Bruce mentioned earlier there’s currently a CBP exams, Certified Bitcoin Professional that you can take outside and see Joshua here who’s been sitting at the table across from the coffee. This is the kind of personnel certification that C4 is best known for. A lot of people have heard of CBP, the Certified Bitcoin Professional.

There is a new certification coming out soon. We’re doing some trials with some test questions now called the Certified Bitcoin Expert or CBX and there’s some more coming in the future.

What we’re going to talk about today is not the personnel certifications side but the business systems and organizational certification. We’re talking about the cryptocurrency security standard. So this is not something that an individual would apply for. This is an organizational best practice that a company would audit against and certified itself against.

And there’s a personnel certification CCSA that we’ll talk about next in this presentation a bit further down which is for auditors to audit compliance with the security standard.

So, a quick overview of what the CCSS is:

It is a security standard for the storage and use of cryptocurrency keys. It provides clear guidance for developers or for companies that maintain cryptocurrency systems. People like – exchanges or Bitcoin gambling sites or really any kind of Bitcoin system that is going to store and use these keys. If they want to know what they need to do in order to be secure CCSS provides guidance for them. But it also gives clear measurement criteria for auditors.

Let’s say your insurance company wants to insure your Bitcoin holdings but they’ve no idea how you’re actually securing your coins. Well, what CCSS will provide is a measurement criteria for how secure your coins are. That could even lead to discounts potentially on your premiums based on how you are securing it.

Now, when we started this project my old job I used to be a security auditor, information security auditor and whenever we do an audit we’d do it against the PCI standard or against the ISO 27001 standard. Every industry has a standard. If you’re going to store credit information you need to store them in encrypted or tokenize, the way that the PCI standard dictates. If you are storing healthcare information there’s actually legal legislation that specify exactly how you need to encrypt all of your patient healthcare information.

The food industry has HACCP on how to create the foods safely and auditing has SOC 2 but when it came to Bitcoin and cryptocurrencies there is nothing that specified how you should store your keys in order to be safe. And without a standard everyone sort of left to go their own way. Now, some companies have done a great job securing their coins that never had any problems but then there are a couple of other companies who have recently had some problems. So rather than going your own way you having a standard allows you to at least make sure you’re getting other marks.

ANDREAS ANTONOPOULOS: You may have noticed that about half the standards on the previous slide were standards that are organized and delivered by industries, so self-regulation. And half the standards were mandates imposed by governments. And so one of the really important reasons why we’re developing and have developed this cryptocurrency security standard is because if we don’t have best practices and standards for evaluating against those best practices and regulation within the industry is a series of failures will bring us mandates from governments and guess what, they don’t know how this technology works. So they’re going to mandate things based on what they understand probably banking and it’s not going to fit, right? The shoe is not going to fit.

What we’re trying to do here is develop standards with a clear understanding of how the technology works and the really important nuances that come up because of this technology so it fits our industry. If we don’t do it ourselves it’s going to be done to us.

MICHAEL PERKLIN: That’s right. And a lot of you are familiar a lot of the really technical things we need to do to secure Bitcoins whether it’s encrypting your wallet or using a secure random number generator or using this hardware, using that software and while both of those are very important that’s not the only thing. Some of the recent hacks that have affected some of these companies have actually been non-technical in nature. So the policies and procedures are equally as important.

If a company has very secure hardware and software but the secretary puts down the password on the posted note and slaps it on her monitor it doesn’t matter if she’s using the best encryption with the longest password. Someone can just look at that posted note and you’re going to breach it just the same.

ANDREAS ANTONOPOULOS: In fairness it’s usually not the secretary we’re both auditors, we’ve done this job before and I can guarantee you it’s usually the CEO who does that.

MICHAEL PERKLIN: It’s true. So, here we come to definition and information system. An information system is a combination of the hardware, the software, policies, procedures and personnel. All five of these needs to come together the same otherwise the system is not secure. Just like a chain that’s, you know, held together with a twist tie. Who cares how strong the other links are when one of these links in the chain is a twist tie. And that’s sort of how the CCSS was built.

There are three levels of increasing security depending on how you are securing things and they each build on top of each other. If you’re worried about these things you are considered Level One. If you’re worried about these things and those things you are Level Two. And Level Three builds on Level Two and Level One as well. You can sort of think this as, you know, extremely secure, very secure and secure but we just called them Level One, Level Two and Level Three.

ANDREAS ANTONOPOULOS: One other to understand with any security standard is the security standard is there to give you guidance of what the minimum requirement you should do. It’s the lowest rung on the ladder. Now, surprisingly even though it’s the lowest rung a lot of companies don’t even do that. But the goal here is the companies that implement this meet and exceed each standard level.

MICHAEL PERKLIN: So, to give you a visual overview of how the standard sort of fits together. 

Here’s an example audit that would have been completed against Acme exchange company. Obviously this is not real but you could see a couple of things from this infograph. There are ten different aspects within the security standard and each one of these ten can be graded as Level One, Level Two or Level Three. You could see here that the first aspect Key/Seed Generation was graded as Level One but the second aspect Wallet Creation was graded all the way at Level Three.

There are a couple here that were graded as Level Two. Now, the one thing that’s in common with all ten of these is that they’ve all reached Level One in all ten of them. That means that this system is considered a Level One system. Even though they have some aspects that are graded higher the system as a whole is still only Level One.

Now, if they were to beef up the first one, the third one, the seventh and the ninth they could reach Level Two or they could even reach Level Three if they beef them all up all the way to Level Three but this just shows how they each build on each other.

ANDREAS ANTONOPOULOS: Again, that’s the weakest link approached so they’re Level One because that’s their weakest link.

MICHAEL PERKLIN: So, a quick note about each of these ten aspects. Each of these ten affected different area of your information system. The first one most in the audience will be familiar with this from some of the attacks that have occurred on random number generators, it’s the Key/Seed Generation.

This aspect governs how you create the key material that you use to store your information. Are you using a secure random number generator or somebody maybe hacked this random number generator in a way that you’re always going to generate a key that they know and they can predict.

The second one is closely linked but it’s certainly different, Wallet Creation. Now, that you have a key or two keys or three keys or multiple keys how do you combine those keys in a way to create a destination for funds. How do you create an address or a P2SH string. And the way that you combine them can also affect your security as well.

The third one is Key Storage. This one’s fairly self-explanatory. Now that you have these keys created how do you store them in a way that cannot be accessed by an attacker, that cannot be destroyed by an environmental disaster or something like that. The way that you store these keys is very important to make sure that they can’t be lost easily.

Key Usage is – this governs when you take those keys out of storage to use them whether it’s a signing agent that’s placed online or maybe some kind of an offline signing device. The process and the procedure that you go through when you use these stored keys to calculate a digital signature so that the transaction can be validated by the Bitcoin network.

Next one is the Key Compromise Policy. This one is an interesting one and governs what your business is doing to prepare for when a key becomes compromised or to prepare for when an operator has become compromised. There are many different types of compromise but all of them results in the exact same thing. You need to fix the compromise and remove it.

One example could be let’s say, you have your laptop which has your private keys on it. You leave it on your car go into the mall and come back and you see that the window of your car has been smashed. Now, luckily the thief took a few other things from your car but not your laptop but it’s possible they could have accessed your laptop. It’s possible they could have copied something and now trying brute force it. That’s a compromise situation.

So, having a bunch of clear steps of what you need to do in order to resolve that compromise is necessary for secure system.

Next is the Keyholder Grant/Revoke Policies & Procedures. This is sort of like the HR or the user administration for when your organization chooses who will have access to your keys. Does everyone in your organization have access to the keys and anyone can sign equally? Or are there a few key personnel only who have access to the keys?

Those key personnel how did you choose them? Just some guy off the street or did you do maybe a background check or do you know them very well. Those types of questions govern the security of your system because if a bad actor has access to your keys the bad actor can steal your money.

Fourth from last is the Third-party Audits & Pentests. No matter how smart any one man is, no matter how smart a team of people are that attack a problem they’re always looking at everything from their two eyes from their viewpoint. But with any system just because everything looks great from my viewpoint it doesn’t mean that, you know, if Gavin looks it from his viewpoint it’s going – maybe he’ll see something that I didn’t see. You also need to have a third-party take a look at what you’re doing even just to validate what you’ve done or maybe to point out things that you didn’t see yourself.

ANDREAS ANTONOPOULOS: This is also a good example of parts of the cryptocurrency security standard that are repeating. So, you know, for Level One you must have an audit but as you go up in the levels you must have more frequent audits. So just because you achieve a level in the cryptocurrency security standard doesn’t mean you keep it. You have to continuously audit and prove that you are maintaining that level as things change in the organization.

MICHAEL PERKLIN: Third from last is the Data Sanitization Policy. All of our phones get old and get replaced. All of our laptops will get replaced eventually. It’s just a matter of fact and they are, you know, technological error. If those devices held key material on them at any one point it needs to be scrubbed before that device is tossed or recycled or donated to another individual. So, what does your organization do in order to ensure that the data is sanitized before these devices are recycled or disposed off.

Next to last is the Proof of Reserves. This governs how your organization proves the reserves that they have either internally to themselves, externally to an auditor or maybe even to their customers so that there is assurance that, you know, if I put in two Bitcoin into my account on this exchange I know that that exchange actually has them. Without a proof of reserves internal ledgers may not match external ledgers and loss of funds can occur.

ANDREAS ANTONOPOULOS: (0:18:22)

MICHAEL PERKLIN: Yeah. Finally, Audit Logs. Now, something bad will always happen eventually, even if it’s just an attempt of something bad. If it didn’t succeed you still to have some kind of investigative evidence for what happened or what almost occurred. If your application keeps judicious logs about every time an authorized operator has logged in or what they do when they are logged in or even non-authorized operators or non-authorized attempts.

By having some kind of an audit log you are able to investigate any kind of incident or potential incident which can maybe even recovered funds if the granularity of this log is thorough enough.

So, those are the ten in a nutshell. That’s a very brief overview of how they work but each of these goes into a lot of depth actually in how it prescribes what you need to do in order to keep a secure system. Andreas is going to walk through the very first one, Key/Seed Generation in more detail. Every single one of these has equal level of detail as Key/Seed Generation but let’s just focus on that one for now.

ANDREAS ANTONOPOULOS: So, all of this information is online. You can see the full standard with all of the details. This is the second level down so previously we looked at the ten domains, if you like, at the highest level. This is one domain, Key/Seed Generation and this has three controls. These three controls have specific levels for certification and below that there’s even more details. So if you dig in even below this level you’ll find much more detailed explanations of what the requirements are for each of these controls.

So the way you read this is the horizontal lines are the controls and the vertical columns are the – what is required at each level of certification. So the first control for example, is whether the operator who creates the seed. And then we’ll look at Level One, Level Two and Level Three requirements across these controls.

So, for Level One in Key/Seed Generation the actor performing the signing must create their own key or key material. Let’s give you an example. Let’s say you have a multisignature address which requires three signatures. Is it okay for a system administrator to generate all three keys on their own laptop and then hand one key to the CEO, one key to the CFO and one key to the CTO? According to CCSS, no. that would make you uncertified.

Even at Level One each actor the CEO, CFO, CTO need to generate their own keys independently and no one party can have access to all the keys at the same time otherwise what happens if their laptops compromise, what happens if that administrator is rogue, what happens… so that weakened the security.

The second control is about how the keys generated themselves. So, how do you generate random number? The number of hacks and problems we’ve seen in Bitcoin just off this single control is already in the dozens. Random number generation is a key component of cryptographic security.

So, we require that a deterministic random bit generator is used that is compliant with NIST 800-90A which is the National Institute of Standards & Technology. It’s a federally used standard for security that prescribes specific algorithms that can be used and techniques that can be used to generate random numbers. Now, both of these have to matched at a very minimum to be Level One certified under CCSS.

Now, if you then look at Level Two which is the next column you have the two original controls with some additional requirements but you also have a third control which is validation of the random bit generator. So let’s look at Level Two.

So, if you’re trying to achieve Level Two certification you have to fulfill the requirements of Level One as before each actor creates their own key and the random number generator needs to be compliant but in addition to that the entropy and algorithm must be validated before every seed is created. So you have a system that generates keys.

How do you know it hasn’t been tempered with? How do you know the software on that device hasn’t been changed? Even in the very simple case let’s say you download Electrum and you’re going to use that to generate a Wallet. Have you validated the source code, fingerprint matches, the published fingerprint by the software built or software developer.

And second requirement there is that the deterministic random bit generator is seeded with a cryptographically secure source of entropy that is external to the system. So it’s not enough to just say well, let’s just take the clock and throw it into the random number generator to seed you need a stronger source of entropy and so the specific requirements under that.

MICHAEL PERKLIN: Now, one other thing I’ll add is in addition to validating the software or the algorithm that’s going to be generating your key you also need to validate the entropy. Now some people like to use maybe a deck of cards randomly shuffled as part of their entropy. What this would cover is have you gone through the deck of cards to make sure there is only one of every single card and every single card is present because if there were duplicates that would affect the entropy.

You know if you’re going to be accepting like Electrum is it pulling from (0:23:55) within the system or is it pulling from something else. So, double checking not just the algorithm but where the source of randomness are equally important.

ANDREAS ANTONOPOULOS: Yeah. Two examples of hacks that or problems box in fact that led to problems in Bitcoin here – one was using an operating system delivered source of entropy that in some installations the operating didn’t exist and what it then degraded to was a much worse source of entropy.

Or in another case we saw one of the wallet companies using a source of entropy that was external which was a call in http call to random.org and when that was returning an http error code because they had now implemented https and refused connections it would take the error code as the source of entropy. Now, if you simply had a test there that took it three times and made sure that it’s not the same every time that part would have been caught. So it may involve changes to code or process to ensure that doesn’t happen.

So then we go to Level Three and Level Three is almost the same with Level Two. You still need to fulfill all of the Level Two stuff but you need multiple cryptographically secured source of entropy that have been combined in a cryptographically secured manner or you need perhaps a non-deterministic random bit generator such as a hardware random number generator that is external to the system that uses industry standard statistical test to be validated.

So for example, if you have an external hardware FIPS device that has been validated under NIST standards then that device would appropriate to use for entropy sourcing.

MICHAEL PERKLIN: So, we just take a deep dive into one of the ten aspects – the first one Key/Seed Generation but each one of these is equally as in-depth throughout them. You know Key/Seed Generation had three controls combined across all ten of them. There are 34 separate controls that each govern whether that aspect will be graded as Level One, Level Two or Level Three.

ANDREAS ANTONOPOULOS: Now, just quickly before we leave that topic I’m seeing a lot of people in the audience who are going “Holy yeah,” they’re looking at this and thinking “Oh, maybe that’s not secure enough.” Well, (0:26:27) level set here. There’s two aspects to this. The first is a lot of Bitcoin companies do not even fulfill Level One or not even close. So, we would be looking at a significant improvement in the industry even if this is the Level One requirement that we had.

Secondly, if you think that this is not sufficiently secure or you have other concerns that are not covered by these domains or you look at this controls and you think well, maybe there should be another control for something else. Great. Fantastic. We didn’t write this.

What we did is we created the collaborative process openly on GitHub where everyone contributed ideas and that process is ongoing because this is a draft standard. Please give us your feedback. Make this better. And so, that way we can deliver real industry standard for security. It has to be really good in my opinion at the moment and would increase security dramatically but we are looking for feedback which we’ll talk about next.

MICHAEL PERKLIN: Quick question?

ANDREAS ANTONOPOULOS: That’s a great question. Let me repeat the question first. The gentleman asked – he’s working with a number of Bitcoin technology companies as partners. If you’re doing something that involves perhaps other partners, other software providers etc. how do you coordinate certification among them. And so, do you want to take that and answer it?

MICHAEL PERKLIN: Well, some of your question is answered in the next few slides. So, why don’t we take a second step at that towards the end of (0:28:01) if any part of it is still left unanswered. Is that all right?

ANDREAS ANTONOPOULOS: Well, that’s a great question. Why do you draw the line between this and other standards, standards more generally in security? This is not intended to be a comprehensive security standard for everything a company does in this space. This is focused on particular nuances of aspect that are particular to cryptocurrencies.

You would supplement this with other standards and good information security practices that have already been published. What we’re addressing the gap, the things that are highly important in our particular industry. So you wouldn’t use this in isolation.

Any company that’s doing any form of software engineering would have standards for software engineering practices and information security, system security and all of the other standards that exist in the industries including how you put things on the App Store for example, software signing and a lot of other standards that already exist. We’re not trying to reinvent those. We’re trying to fill specific gaps that are for cryptocurrencies.

MAN #1: But shouldn’t you require this – is there some level that there’s supporting (0:29:14) and Android in particular is the best one. There’s a lot of bad practices with how certificates were handled and things of that nature and the fundamental (0:29:26) and the Google App Store is not required (0:29:29) and security.

MICHAEL PERKLIN: There’s definitely vulnerability with the Google App Store and as Andreas said the CCSS supplements other existing certifications. For example, your organization should still likely comply with ISO 27001 if you want to cover everything that the 27001 covers. If you are going to be dealing with healthcare as well you still have to comply with HIPAA and all these other things.

What CCSS focuses on is the storage and use of cryptographic keys because until this existed there was nothing that dictated how you should do it leaving everyone to sort of do it on their own.

ANDREAS ANTONOPOULOS: And if there are gaps where you see specific areas that needs to be supplemented by reference to existing standards, as you notice in the example we provided we don’t reinvent the wheel because in fact in cryptography build your own is a deadly mistake that causes a lot of problems, right?

If there are standards out there you use the standards that have been tested and peerviewed extensively. So we refer to NIST and Diehard and a whole other set of external sources for validating these practices. If there are gaps and we need to refer to more, please contribute. That would be excellent.

MICHAEL PERKLIN: We have time for other questions towards the end. Why don’t we just skip through the (0:30:49) the slide that may answer some of the questions that you have already and we’ll pick up the questions afterwards.

So, there’s a variety of really good reasons to use CCSS. I mean if you want to validate what you have already done or what you’re about to build it’s a great tool to do that. Just to give yourself reassurance that you are covering as many bases as possible. If you have customers of your system they may find it useful to know that the way that you’re storing their funds is compliant with the standard rather than just sort of doing it the way that you think you should do it which, I mean has worked for some companies definitely but definitely hasn’t worked for a few others.

In order to use a standard…

ANDREAS ANTONOPOULOS: Go ahead.

MICHAEL PERKLIN: Yeah. In order to use a standard it’s all freely available on GitHub. Now, this (0:31:44) here at the top is where you could see all the details of everything, you can get to it, of course, from cryptoconsortium.org from their website and all the source for building what you see here is stored in GitHub.

We’ve had a number of pull request from companies such as the BitGo, (0:32:04) Gem, Cyphrex, from a lot of companies that are active in this space and improving this. We even had some commits from other organizations such as Deloitte and non-crypto organizations because they recognize that having a standard against which you can audit a company is a very useful tool to make sure that the safety of all of our funds is improved.

One of the easiest ways to use this is to assess it yourself. There is a blank checklist that you can get from the website that allows you to go through everything on your own to see where you would fall within it. This allows you to spend time your beefing up this policy or changing the way that you store your keys or whatever it is that you feel that you’re lacking in.

Once you’ve done this when you engaged a third-party for security audit it makes it a lot cheaper and a lot faster because you don’t need to go back three or four times with your third-party auditor as they say this change to the other because you’ve done it yourself, you’ve fixed up most of the bugs now there’s only just tying up a few loose ends so it actually makes the process of securing your system a lot less expensive by going through the checklist on your own.

ANDREAS ANTONOPOULOS: And what is the cost for downloading this checklist, Michael?

MICHAEL PERKLIN: Absolutely free.

ANDREAS ANTONOPOULOS: Yeah.

MICHAEL PERKLIN: All these information is published with a very liberal license. Feel free to copy, feel free to modify, feel free to use it however you wish.

ANDREAS ANTONOPOULOS: When you said we’re like ISO that’s one of the big departures because ISO charges like six hundred bucks for a PDF so, yeah, this is all-free collaborative and community developed work.

MICHAEL PERKLIN: One of the most recent usages of CCSS is it was posted online at bitcoin.com/security. They contacted us and said we really believed that this industry needs a security standard like the one that you’ve developed. We want to host it on our own website can we copy the content? We just referred them to the license yes, use it however you see fit.

In the near future we’ll be launching a new personnel certification similar to the Certified Bitcoin Professional or Certified Bitcoin Expert Exams. There’s going to be a CCSA certification, Certified CCSS Security Auditor.

This is someone who is thoroughly familiar with all of the aspects of the standard and is able to go out into an organization and say you are Level One, you are Level Two or you are Level Three. Also, only CCSAs who are familiar with the standard they’re going to be the only ones who are able to publish CCSS audits on crytoconsortium.org so that all of us when we’re about to use, you know, bite envelope or some other exchange we can now look them up and say they were audited on this day and this time by John Smith and they were graded as a Level Two system.

And, of course, all of these audits will be timestamped into a Blockchain as well but we’ll be hosting them online for anyone to reference if you do want to look at how the security is implemented for that system.

ANDREAS ANTONOPOULOS: And C4 doesn’t charge anything for you to audit your company because we don’t do the audits, the organization is a stewardship organization. You would go to a third-party auditor to do this audit and we expect a lot of both new companies that are involved into doing these consultants, etc. or may choose to become CCSAs or many of the existing security auditing companies that are out there that do things like HIPAA audits and PCI audits would add to their skill sets to CCSA audit capabilities they can audit these companies.

MICHAEL PERKLIN: There are a couple of ways that you can help us as well. As Andreas mentioned earlier this is still in draft form. It’s been in draft for eight months so far and the reason for this is even though we drawed on the experience and knowledge from a lot of people at a lot of really high-profile Bitcoin companies to pull together all of the best practices into one document. As much as we think these groups of people are they may have missed something and maybe you can find out what’s missing.

So because it’s all hosted on GitHub feel free to fork it, edit it and submit your pull request. Feel free to add an issue just asking question now why is this like this and not like that. I think it will be smarter the other way. Whatever, review it and even if it’s just reading through the existing issues and providing your suggestions or your viewpoint on what other people are already discussing will help to improve the standard that we are building for our own industry for self-regulation.

ANDREAS ANTONOPOULOS: So, those who are interested in this kind of thing just to give you a little preview there’s three interesting topics being discussed at the moment as part of this that are either issues or pull requests that have come towards implementing different aspects of the standard. One is revision of the entropy side of key generation so what kind of standard do we use for random number generators etc.

The second one which is rather interesting is how to develop processes and procedures for maintaining consensus critical systems which is a completely new area in system administration, you know, how do you maintain Bitcoin notes that must remain in consensus with the longest Blockchain at the moment.

How do you deal with alert notification and long forks that are unanticipated and how do you maintain that code base? How do you update and upgrade it and check the code? How do you get the code from secure sources? We’re talking about that.

Another one is how do apply signatures securely which may have relationship to things like malleability that Greg was talking about this morning, you know, for example lowest values or things like that.

MICHAEL PERKLIN: And finally, as mentioned at the very beginning of the presentation C4 is a non-profit organization and we depend on donations by people who use our standards. These funds go towards improving our programs and making sure that these standards have the attention on them that we believe that they definitely need.

We do have a lighthouse campaign currently open where about 52% of the lighthouse campaign you can find it by going to Project 37 on whitelist or by grabbing our lighthouse project file from our domain/C4.lighthouse-project. And we’re, of course, able to accept donations directly using this nice QR code here while answer any questions that you may have of our standard.

ANDREAS ANTONOPOULOS: So, let me just first address the question we had during the presentation – how do you deal with partners in this space?

So, one of the ways to deal with partners or to use the standard to deal with partners is to ask your partner to do a self-assessment against CCSS and to give your report. So, using the checklist and then using the more detailed stuff write out a report maybe like a 10, 15 page report that says here’s how we do key generation.

Here’s how we’ve chosen to build our wallets. Here’s how what process we have for key compromise policy and document all of the internal processes, standards, procedures, personnel training, all of the things they’ve done in order to achieve what they feel is their level of security they have today. So, then you have a common basis for understanding how your partners are handling security. If that works, once you get some acceptance of that standard then you ask them to audit and do a third-party audit against that standard so you can get higher levels of assurance.

MICHAEL PERKLIN: There was a hand up over here, do you have a question?

MAN #2: (0:39:52)

ANDREAS ANTONOPOULOS: The operational aspect, right?

MAN #2: (0:40:19)

ANDREAS ANTONOPOULOS: Right, that’s a very good point. So, you’re not just looking at auditing a software vendor, you know, it’s of little use for me to go and audit Electrum and then from that derive how you’re using Electrum because you can take a perfectly good piece of software and use it –

MICHAEL PERKLIN: Or hardware.

ANDREAS ANTONOPOULOS: – or hardware and use it poorly. So security is operations and process, its technology and its people and yes, you have to make sure that your technology is properly sourced and you’re outputting certain trust in the technology you’re sourcing but the real mistakes we see again and again and again have much more to do with how you apply that technology. So process and people and those are the weaknesses that are usually exploited by attackers.

MAN #3: (0:41:09) there was a requirement for all wallets to be HD we should not wait conventional (0:41:20) assignment for some specific address HD wallet requires conventional (0:41:30)

ANDREAS ANTONOPOULOS: So, the first draft of the standard you say there was a requirement that all wallets are HD I don’t believe that’s in the current draft of the standard. I think for Level One certification you don’t have to use HD wallets. There are certain best practices that are recommended in there.

Those have a lot to do with maintaining privacy for your clients. So they have to do with address reuse rather within the security of the wallet. If you reuse addresses in Bitcoin what that does is it essentially taints one address with the next address with the next address which significantly reduces the privacy of your customers. If you’re doing that as a commercial wallet that has repercussions that are fairly significant.

Interestingly enough, you know, there are other projects out there that are addressing that issue more specifically the Bitcoin open privacy project that I am involved in with Christopher (0:42:24) that ranks wallets based on how well they handle privacy. So that’s not a security certification, that’s a specific privacy ranking.

MICHAEL PERKLIN: And just another point to your comment about the operational side. I absolutely agree that that is far more important than the technology you choose. We have very smart people who are making very capable software and very capable hardware. A lot of them are actually in this room right now. Simply using their software or their hardware is not enough. The procedures and the policy that your organization has is equally important.

One example is recently there is a social engineering attach against a rather large Bitcoin company and it occurred by somebody putting a Bitcoin address in an e-mail saying “Hey, this customer wants to withdraw money to this Bitcoin address. Please process the withdrawal.” Now if that organization has a policy in advance that no Bitcoin addresses will ever be in e-mails. That’s just not how our company does business, this is the policy. If you’re asking for withdrawal, you know, Customer 589 needs a withdrawal.

Well, there’s already a preset database with present keys and preset addresses for Customer 389. Anybody can look it up and processes withdrawal to that address in one go. The moment an address appears in an e-mail that would be a red flag. This is against our policy, we don’t put addresses in e-mails. This has got to be some kind of a fishing attempt. So by doing a little bit of work in advance to set up secure by default systems you can avoid a lot of these types of attacks just by policy alone.

ANDREAS ANTONOPOULOS: You all noticed these outliers, these exceptions. You know one of the really common things we see in security attacks is that attackers take advantage of emergencies and sometimes sophisticated attackers create emergencies to take advantage of them.

So they’ll create a weakness in the system or they’ll identify weakness in the system in the way you handle things when there’s say, a denial of service attack and, you know, some companies will like draw their standard process and go into emergency mode, side channels started to being used for communication and things like that so a sophisticated attackers will actually attack your system, creates an emergency and then exploit that emergency to attack you. We see this happening in Bitcoin already.

That’s where well-defined procedures within a company and procedures for handling emergencies that are defined in advance prevent you from going into well, screw it. We’ll just do anything right now just to solve the problem and then you get attacked.

MICHAEL PERKLIN: We have some time for a few more questions.

MAN #4: Sometimes the failure analysis can be more (0:45:14) than describing bad practices or involved in including anonymized failure scenario (0:45:23)

ANDREAS ANTONOPOULOS: Well, with the number of companies in the Bitcoin space right now anonymized failure analysis wouldn’t be very anonymized. I think we’ve given three examples and even though we’re trying to be discreet because this is not about assigning (0:45:35) you know that in an immature industry everyone is getting hacked eventually.

The question is how bad is it, how much do you mitigate and what the consequences are? Yeah, I don’t know yet whether that’s something that would be under C4 or whether there might be avenues for doing post-incident analysis and post-mortem essentially to gain lessons from that. But it’s a fundamental part of the security life cycle is looking back and identifying what went wrong, how it went wrong, what others can learn from that and doing open disclosure of that as much as possible.

MICHAEL PERKLIN: There is one aspect that covers audit logs and that make sure that your system is tracking actions thoroughly enough that way when there is a failure and you do have to do failure analysis, you have something to analyze. Without those types of audit logs and without those fingerprints, all those bread crumbs that your application is leaving when you try to do failure analysis you have nothing to analyze.

So in a way part of what you’ve suggested is covered by the standard but Andreas is right those types of anonymized statistics, that’s not what C4 is creating here. We are creating an open standard and we’re making sure that as suggestion from the best and brightest in the industry, even the unknown people in the industry, as suggestions come in for improving the best practice guidelines those improvements get reflected in the standard so that all of us can make use of their suggestion.

ANDREAS ANTONOPOULOS: The main (0:47:10) no need to reinvent the wheel here. So in the broader security space and information security there are already organizations that do very extensive statistic analysis of both denial of service and malicious attacks and accidental breaches.

So, for example, every year a research group within Verizon publishes an analysis of tens of thousands of security incidents that are recorded with information on what the sources were, how they got in, what they broke etc. etc. there’s no reason to redo all of that for Bitcoin.

Perhaps in the long run Bitcoin will just be part of the broader information security space and we’ll start seeing that kind of analysis just be included in the overall space.

MICHAEL PERKLIN: Bruce, do we have time for another question?

BRUCE FENTON: Yeah.

ANDREAS ANTONOPOULOS: Yeah, one more.

BRUCE FENTON: (0:48:09) two more.

ANDREAS ANTONOPOULOS: Two more. Do we have two more, though?

MICHAEL PERKLIN: Well, I think that means we’ve done a great job of describing this.

ANDREAS ANTONOPOULOS: Oh, one more there, okay. Yeah, yeah.

MAN #5: (0:48:19)

ANDREAS ANTONOPOULOS: (0:48:20)

MAN #5: My name’s Steve and I’m from Australia (0:48:23) my apologies. One of the things that has inspired me over the couple of years (0:48:28) speech watching you, Andreas, and from you and others is the conversation that Bitcoin collapses into a technological (0:48:40). We all know that the diversity and possibilities (0:48:45) around an idea of consensus that’s not the technological…

ANDREAS ANTONOPOULOS: Well, let’s take that question for – I have presentation after lunch which might be a bit more generic rather than this one might be a bit off on the tangent from what we’re talking about in the security standard. Now think of your question and I’ll absolutely answer that next. All right, one last one.

MICHAEL PERKLIN: Michael.

MAN #6: (0:49:26)

ANDREAS ANTONOPOULOS: Well, I can answer from my experience yes, I’ve spoken to insurance companies quite extensively. They’re still trying to grapple with the implications of this technology, they don’t really understand it. So, one of the companies that I’m involved in Turkey Solutions does multisignature key management, key generation and signing as a third-party independent agent.

And so we talked to insurance companies and we say “Look, can you help us handle the insurance implications of some of these.” And they say “Okay, so how much money you’re holding?” Well, none. No money. We don’t control any of that, we have one of a multisignature system and they say “Okay, so how much money is the multisignature holding?” Well, we don’t know.

We don’t know because we don’t want to know because that leaks information from the service provider. We can build the entire tree on our own. We don’t want to know because otherwise we’d be able to track every transaction the customer do so we don’t know how money is under management and in any case we don’t control it. Can you insure us? And they say “Sure, five thousand a month.” How does that sound?

I just pulled it off the tree and there it is five thousand a month and you know the problem right now is that even if you pay that five thousand a month which I’m not, I’m not going to, what happens next? You get a claim and I think we recently had an example of exact what happens when the claim comes along and they go well, you know, of course Bitcoin isn’t money and even if it was money we don’t understand signatures and where the signatures anyway and who made the transaction? Bye-bye. And then you’re in lawsuit land.

Part of having industry standards and best practices is narrowing that conversation down to more tangible things because there isn’t any actuarial information yet in the insurance industry to evaluate the risk. So if you hold five million dollars and the risk is X what is the risk if you hold one key out of three for five million dollars?

This is still very, very early days. So I think insurance is going to be an uphill battle and a lot of it will involve legal precedent before we actually get to things. But I can tell you that the insurance companies are very interested in this kind of work.

MICHAEL PERKLIN: Absolutely.

ANDREAS ANTONOPOULOS: Because it gives them a basis to evaluate things and also to compare situations which allows them to start building the actuarial data they need to provide rates.

MICHAEL PERKLIN: So, it looks like we’re out of time but one last that I will mention because we’re about to go out for lunch, the certified Bitcoin professional exam is a twenty-minute exam, all multiple choice and if you register for it at the beginning of your lunch as you’re eating your pizza you can just had multiple choice questions on your phone.

If you pass it by the end of the day you can walk out with a free certificate, you can take back to your employer and say “Look, what I’d learned, look what I’d accomplished at DevCore. Now if you don’t want to write the exam today because you’re not as good as you think you are the coupon code that we’re giving out today you can use it anytime between now and the end of the month to get the free exams, you can write the free exam at home. And once you’ve added the coupon code you can choose to write the exam next year if you like.

The only difference is when you do pass we’ll have to ship you your certificate instead of handing it to you here in person so we will charge you for the shipping. But other than that it’s a free exam that you can all take right now during your lunch.

ANDREAS ANTONOPOULOS: Thank you very much, everyone. 

Written by Michael Perklin on November 5, 2015.