Maintaining bitcoin and other cryptocurrencies causes about 0.3 percent of global CO2 emissions. That may not sound like a lot, but it’s more than the emissions of Switzerland, Croatia, and Norway combined. As many cryptocurrencies crash and the FTX bankruptcy moves into the litigation stage, regulators are likely to scrutinize the cryptocurrency world more than ever before. This presents a perfect opportunity to curb their environmental damage.

The good news is that cryptocurrencies don’t have to be carbon intensive. In fact, some have near-zero emissions. To encourage polluting currencies to reduce their carbon footprint, we need to force buyers to pay for their environmental harms through taxes.

The difference in emissions among cryptocurrencies comes down to how they create new coins. Bitcoin and other high emitters use a system called “proof of work“: to generate coins, participants, or “miners,” have to solve math problems that demand extraordinary computing power. This allows currencies to maintain their decentralized ledger—the blockchain—but requires enormous amounts of energy.

Greener alternatives exist. Most notably, the “proof of stake” system enables participants to maintain their blockchain by depositing cryptocurrency holdings in a pool. When the second-largest cryptocurrency, Ethereum, switched from proof of work to proof of stake earlier this year, its energy consumption dropped by more than 99.9% overnight.

Bitcoin and other cryptocurrencies probably won’t follow suit unless forced to, because proof of work offers massive profits to miners—and they’re the ones with power in the system. Multiple legislative levers could be used to entice them to change.

The most blunt solution is to ban cryptocurrency mining altogether. China did this in 2018, but it only made the problem worse; mining moved to other countries with even less efficient energy generation, and emissions went up. The only way for a mining ban to meaningfully reduce carbon emissions is to enact it across most of the globe. Achieving that level of international consensus is, to say the least, unlikely.

A second solution is to prohibit the buying and selling of proof-of-work currencies. The European Parliament’s Committee on Economic and Monetary Affairs considered making such a proposal, but voted against it in March. This is understandable; as with a mining ban, it would be both viewed as paternalistic and difficult to implement politically.

Employing a tax instead of an outright ban would largely skirt these issues. As with taxes on gasoline, tobacco, plastics, and alcohol, a cryptocurrency tax could reduce real-world harm by making consumers pay for it.

Most ways of taxing cryptocurrencies would be inefficient, because they’re easy to circumvent and hard to enforce. To avoid these pitfalls, the tax should be levied as a fixed percentage of each proof-of-work-cryptocurrency purchase. Cryptocurrency exchanges should collect the tax, just as merchants collect sales taxes from customers before passing the sum on to governments. To make it harder to evade, the tax should apply regardless of how the proof-of-work currency is being exchanged—whether for a fiat currency or another cryptocurrency. Most important, any state that implements the tax should target all purchases by citizens in its jurisdiction, even if they buy through exchanges with no legal presence in the country.

This sort of tax would be transparent and easy to enforce. Because most people buy cryptocurrencies from one of only a few large exchanges—such as Binance, Coinbase, and Kraken—auditing them should be cheap enough that it pays for itself. If an exchange fails to comply, it should be banned.

Even a small tax on proof-of-work currencies would reduce their damage to the planet. Imagine that you’re new to cryptocurrency and want to become a first-time investor. You’re presented with a range of currencies to choose from: bitcoin, ether, litecoin, monero, and others. You notice that all of them except ether add an environmental tax to your purchase price. Which one do you buy?

Countries don’t need to coordinate across borders for a proof-of-work tax on their own citizens to be effective. But early adopters should still consider ways to encourage others to come on board. This has precedent. The European Union is trying to influence global policy with its carbon border adjustments, which are designed to discourage people from buying carbon-intensive products abroad in order to skirt taxes. Similar rules for a proof-of-work tax could persuade other countries to adopt one.

Of course, some people will try to evade the tax, just as people evade every other tax. For example, people might buy tax-free coins on centralized exchanges and then swap them for polluting coins on decentralized exchanges. To some extent, this is inevitable; no tax is perfect. But the effort and technical know-how needed to evade a proof-of-work tax will be a major deterrent.

Even if only a few countries implement this tax—and even if some people evade it—the desirability of bitcoin will fall globally, and the environmental benefit will be significant. A high enough tax could also cause a self-reinforcing cycle that will drive down these cryptocurrencies’ prices. Because the value of many cryptocurrencies rely largely on speculation, they are dependent on future buyers. When speculators are deterred by the tax, the lack of demand will cause the price of bitcoin to fall, which could prompt more current holders to sell—further lowering prices and accelerating the effect. Declining prices will pressure the bitcoin community to abandon proof of work altogether.

Taxing proof-of-work exchanges might hurt them in the short run, but it would not hinder blockchain innovation. Instead, it would redirect innovation toward greener cryptocurrencies. This is no different than how government incentives for electric vehicles encourage carmakers to improve green alternatives to the internal combustion engine. These incentives don’t restrict innovation in automobiles—they promote it.

Taxing environmentally harmful cryptocurrencies can gain support across the political spectrum, from people with varied interests. It would benefit blockchain innovators and cryptocurrency researchers by shifting focus from environmental harm to beneficial uses of the technology. It has the potential to make our planet significantly greener. It would increase government revenues.

Even bitcoin maximalists have reason to embrace the proposal: it would offer the bitcoin community a chance to prove it can survive and grow sustainably.

This essay was written with Christos Porios, and previously appeared in the Atlantic.

Read More

Have you ever heard the saying that the greatest benefit of the cloud is that limitless resources can be spun-up with just a few clicks of the mouse?  If so, you would be best served by forgetting that saying altogether.  Just because cloud resources can be spun-up with a few clicks of the mouse does not mean that they should be.  Rather, prior to launching anything in the cloud, careful consideration and planning are a necessity.  Otherwise, your company or governmental entity might end up in the news for a security blunder that was easily avoidable. 

This blog series will focus on three Amazon Web Services (AWS) security steps that any entity can employ to immediately and dramatically improve their cybersecurity preparedness.  Specifically, we will discuss 1) setting up Identity and Access Management (IAM) properly, 2) avoiding direct Internet access to AWS resources, and 3) encryption for data in transit or at rest.  These steps can be followed for entities that are either new to AWS or existing customers.  Read on to find out if your organization is already following this easy guidance.

Step 1: Use IAM the correct way

According to AWS, IAM enables account administrators to “specify who or what can access services and resources in AWS, centrally manage fine-grained permissions, and analyze access to refine permissions across AWS.”  AWS IAM | Identity and Access Management | Amazon Web Services.  When entities first create an AWS account, the only user that exists is the root user.  This user has the proverbial “keys to the kingdom” and can literally launch cloud environments that would rival Fortune 500 companies in a short amount of time.  In turn, bills commensurate with a Fortune 500 can quickly be accrued, too.  Accordingly, as we will discuss below, protecting the root account is a crucial first step. 

Protect the root account

In addition to creating a sufficiently complex password, multifactor authentication (MFA) must be enabled.  MFA is achieved by using a third-party authentication mechanism.  Since usernames and passwords are stolen with alarming frequency, incorporating login credentials with MFA makes it much more difficult to compromise an account.  This is because the malicious user would need to know a user’s login name, password, and possess the user’s third-party authentication mechanism.  As long as the latter is securely protected, account compromise is nearly impossible (Note: sessions authenticated with MFA can still be compromised via cross-site scripting (XSS) attacks.  As we will learn later, AWS offers a defense against XSS).

AWS supports the following MFA mechanisms: Virtual MFA devices (e.g., Google Authenticator, Twilio Authy, etc.); FIDO security key (i.e., a USB device); and Hardware MFA device (i.e., a physical device that generates random numbers).  IAM – Multi-Factor Authentication (amazon.com).  Conveniently, Virtual MFA can literally be setup in minutes and has no cost associated with it. 

Additionally, if the AWS root account was created with programmatic access keys, they should be deleted immediately.  Even with MFA in place, if these keys fall into the wrong hands, they can be used to launch everything and anything.  These keys are akin to “God mode.”  Something as simple as accidentally posting the keys on a repo like GitHub is all an attacker would need to take over an account.  Hence, it is necessary to delete them and follow the principle of least privilege by divvying up permissions to IAM users, groups, and roles instead.  Let’s discuss how to securely create each of these IAM principals now.

Create IAM users

If all AWS users shared the same login credentials, accountability for individual actions would not be possible.  For example, if ten people have access to the root login account and the account was used to provision Bitcoin mining instances, it would be impossible to determine the culprit. 

Conveniently, AWS provides entities with the ability to provision individual user accounts via the AWS console (users can also be created in the AWS CLI and AWS API).  For each user created, AWS lets you specify what the user is authorized to do with AWS resources on a granular level.  For instance, if a user in the marketing department needs read only access to a specific folder within an S3 bucket, an IAM policy can created to enable this functionality.  By following the principle of least privilege, the user only gets access to what they need to perform their job.  By limiting what a user can do within AWS, it has the effect of reducing the blast radius of the damage that can be caused by a compromised account or disgruntled employee. 

Luckily, AWS has done a lot of the heavy lifting and has already created IAM policies that are unique to job duties.  Account administrators merely need to associate users with the policies that align with their role.  If customization of a policy is required, AWS provides tools that make this process relatively simple as well.  To learn more about creating IAM users, click here: Creating an IAM user in your AWS account – AWS Identity and Access Management (amazon.com). 

However, for business with hundreds or thousands of IAM users, manually associating policies with each user is not feasible.  Especially if job duties frequently change.  Thankfully, AWS has addressed this problem with IAM groups.

Create IAM groups

If employees perform the exact same job duties and need access to the same AWS resources, they should be placed in an IAM Group.  The IAM group has a policy (or policies) associated with it that provides access to specific AWS resources.  Therefore, every IAM user associated with the IAM group has access to the same resources and they are also bound by the same constraints.  Moreover, changes to the policy associated with the group are implemented with immediate effect.  Hence, IAM groups make end user management convenient and efficient.  To learn more about creating IAM groups, click here: Creating IAM user groups – AWS Identity and Access Management (amazon.com).

At this point, you may be wondering how AWS resources like EC2 instances can securely access other AWS resources, or how entities with active directory (AD) can avoid the creation of duplicate AWS user accounts?  The answer to these questions is IAM roles.

Create IAM roles

AWS resources like EC2 instances or Lambda functions can assume an IAM role with predetermined permissions to access, create, update, or terminate other AWS resources.  Likewise, users federated with a Web Identity Provider (e.g., Facebook, Google, etc.), corporate Active Directory, or another AWS account can assume an IAM role with the same functionality.  Like IAM policies associated with users and groups, an IAM role affords the same level of granular control regarding what an AWS resource or federated user can and cannot do. 

Thus, for AWS resources assuming a role, the security implications associated with hardcoding an IAM user’s credentials in an application can be avoided.  Furthermore, entities with AD or other Web Identity Providers will not require their users to create separate AWS login credentials.  To learn more about IAM roles, click here: IAM roles – AWS Identity and Access Management (amazon.com). 

Now that you know the basics and most important aspects of AWS IAM (in this author’s opinion), the next blog in the series will move on to the next step associated with securing your AWS account – limiting direct Internet access to your resources.

Read More