Comments on the ir-File electronic tax filing system

The following text contains some comments on problems with the ir-File system. This is not any form of official report on the system, and is also not a publication of the university or related in any way to the university (it just happens to be where my home page is).

Requirements for an Electronic Tax Return Filing System

Before you go out and build a security system, you have to determine the threat model which you'll be up against, then from that you design a security system which counters the threat(s), and finally from that you produce an implementation. For example when you send credit cards over the net, the threat is that a third party will intercept the information and use it to buy goods at your expense. The response to this threat is to encrypt the card information so that only you and the merchant have access to it. The mechanism used for encryption is usually the SSL (secure sockets layer) implementation in the browser. Neither the merchant nor the customer have much incentive to cheat, because if they do it's their money they lose.

Although this is fine for credit cards, it's entirely the wrong security model for tax returns. With tax records the incentive for a third party to get at your return is minimal (what is there to gain by it, and if you really want the information you slip a couple of twenties to the university student working a summer job doing data entry and they'll pull the file for you). In contrast the customer has a high incentive to cheat, because if they do (and get away with it), it's their money they don't lose. Because of this, there's a strong incentive to file a fraudulent return, and if the tax department discovers this they have to be able to prosecute based on this fraudulent return. A system for filing electronic returns therefore has be designed with two requirements in mind:

  1. It must be as easy as possible for the tax department to prove that the taxpayer filed a fraudulent return.
  2. It must be as hard as possible for the taxpayer to repudiate (deny) filing a fraudulent return.
For an example of how this is applied, when the IRS (the US tax department) set up their electronic filing system a few years back, they designed it on the basis that they didn't really care what you said on your return ("Space aliens ate my taxes"), as long as they could prosecute you for it in court afterwards (this being an incentive to taxpayers to be honest on the return).

Issues with Digital Signatures

Tax returns are normally signed with a handwritten signature. Unfortunately, this isn't possible with computers, so it's necessary to use a digital signature generated by the computer instead. Digital signatures (at least as used in ir-File) are a two-part affair, a private key (supposedly under your control) which you use for signing, and a public key (contained in a key certificate) known to others which is used to verify your signature. Knowledge of the public key/certificate doesn't reveal the private key, so your signature isn't compromised by having the certificate known.

The use of digital signatures has some unusual requirements, particularly where non-repudiation is required. This is brought about by the fact that, unlike a handwritten signature which requires conscious effort by the user, a digital signature is never generated by the user but is generated for them by their computer, and may be generated in a completely transparent manner (that is, the user isn't even aware that they're having something signed on their behalf). For example when you make a connection to a web server running SSL, your computer may be generating a digital signature for you, but you're never told that this is happening - you could in theory be signing your life away without even knowing it (in practice it doesn't work like that because the SSL software doesn't quite do this, see my crypto tutorial if you really need all the gory details).

Although absolute nonrepudiation is impossible to achieve without an unreasonable amount of work, it's possible to achieve at least lawyer-proof nonrepudiation (that is, something which will stand up in court) with some careful design both in the system itself and in the user interface. The next sections will look at the steps necessary to do this, and why the ir-File system fails to meet the requirements.

Before covering this, it's necessary to emphasize the two security issues which are involved here. One is confidentiality, the second is nonrepudiation:

In terms of providing confidentiality, the security measures in ir-File (in particular the use of server-gated crypto (SGC) combined with the fact that anyone who can attack your computer will be interested in your bank account, not your tax return) will protect you - there really isn't much to worry about for end users. The problem is the issue of nonrepudiation, that the system isn't well designed to provide evidence which will stand up to being challenged in court. For end users there's very little effective risk with ir-File as is. For someone trying to use ir-File as evidence in court to prosecute an end user, the story is rather different.

Repudiating the Signature

The point to repudiating the signature is that if you can cast doubt over whether you're responsible for the (fraudulent) return, you can escape prosecution for it, and if you can escape prosecution, the incentive to be honest is much reduced. Because of this, cheating in tax returns is tied directly to the ability to repudiate the signature, so it's necessary to make it as hard as possible to do this. Let's look at some of the ways a customer could repudiate their signature with ir-File.

It wasn't me

When you set up the digital certificate with the IRD, they send you (via snail mail) a user name and password which you use to pick up your certificate. According to the ir-File documentation, once you've received this information in the post, you use it to connect to the IRD system and pick up your certificate, which is used for the signature process. Unfortunately, this makes it trivial to repudiate the signature, since you can claim that someone else who read your mail must have picked up the certificate and filled out the return instead of you (luckily you don't have to explain why anyone would bother with this, merely show that it's possible). For example in any large office the mail will probably go through a secretarial lint filter which handles bills, junk mail, IRD letters, etc. Even if this isn't the case, mail is traditionally left in people's in-trays on desks in plain view of anyone else (in my case since I usually work from home it might sit in plain view of half the people in the building for up to a week before I get to it). In order to successfully prosecute someone, the IRD would have somehow prove that the letter both got to its intended recipient ("I've never seen this IRD letter before, your honour"), and that the recipient used the information in it to pick up their certificate ("Someone else in the office must have copied the name and password from the letter, you can't prove it was me"). Without mounting security cameras on each letter, this is clearly impossible. The security model the IRD have designed for handling the certificate stage of things would be great for sending credit cards over the net, but fails completely for filing tax returns (this is the precise reason why courts have summons served on people directly rather than mailing them out).

A further fault with having the IRD send out the information is that it seems to constitute a shrink-wrap license ("By opening this letter you agree to...") which is something which has been repeatedly ruled unenforceable by courts. At the very least, problems like this will serve to keep a lot of lawyers in BMW's, which probably isn't the intent.

To do it right, the communication needs to be in the other direction. Instead of the IRD sending out the information and then having to prove it got to the user (and noone else) and that they were the ones responsible for using it, the onus should be on the user to prove themselves. The correct way to do it (which is how the IRS is doing it) is to get the user to submit to the IRD a paper document in which they formally declare that the data contained on this document (PIN, password, signature key, whatever) was generated and is stored subject to certain security requirements, that it is entirely under their control, that they agree to use it to form binding signatures for the purposes of filing a tax return, that tax returns which are submitted authenticated with this signature are the sole responsibility of the signer, and so on and so forth. This constitutes a formal, legally binding signed agreement which makes the signer responsible for the tax return, and allows them to be prosecuted in court if there's anything wrong with the return.

Grandma clicks the wrong button and loses her house

The heading above is a colloquial term used to describe a troubling problem with digital signatures, that since the signing action can be involuntary, an inexperienced user could sign their life away without knowing it. Because of this, the signing action has to be very obvious and has to be consciously initiated by the user. For example if you look at your (paper) tax return, you'll notice the following text at the end:

There are penalties for not putting in a tax return or for putting in a false return. Read this declaration and sign the return:

This is a true and correct return for the year ended date. It is also a correct statement of my earnings for the purposes of the Accident Rehabilitation and Compensation Insurance Act 1992.

IRD's lawyers didn't just put this text there for their own amusement. What this text is doing is formally notifying you that by signing the return, you are acknowledging that you have certain responsibilities in filling out the return, and you will be held responsible for any problems in it. The Australian electronic filing project translates this fairly closely into a computer equivalent in that it pops up a very obvious, in-your-face window displaying the information that you are about to sign and notifying you of your responsibilities. Similarly, the IRS system displays the IR 8453 form to the user and then asks them to explicitly authenticate the return with the usual list of responsibilities attached.

In contrast, the IRD system doesn't seem to do this (or at least there's no mention of it in the documentation), which means the return can be disputed in court. Although this sounds like a silly technicality, but the fact that tax lawyers overseas have gone to such a lot of effort to get it right (this particular issue is the main notable feature of the IRS system, and someone working on the Australian project made a point of describing how they were doing this to me) indicates that it's fairly important to get it just right.

Technical Attacks

Another way to repudiate a fraudulent return is to claim that the security mechanisms used are insecure, and that because they can be broken, someone could have done this and filed the fraudulent return (explaining why anyone would bother to do this isn't necessary, all you're interested in is casting doubt on the evidence). Thanks to the reliance of ir-File on ActiveX and Microsoft's CryptoAPI, this is fairly easy to do.

ActiveX it a technology which allows others to run their programs on your machine. When you connect to a web page, it can load an ActiveX program onto your PC and your PC will run it, which is a bit like accepting a floppy disk from someone you've just run into on the street and running the software contained on it on your PC. One comment which has been made about what this does for security is that "ActiveX is like walking into a maximum-security prison, dropping your trousers, bending over, and calling out 'Come and get it boys!'". ir-File relies on ActiveX to function, which also opens the door to anyone else who wants to run their programs on your machine (ActiveX does come with an optional feature called AuthentiCode which allows ActiveX controls to be digitally signed, but this is just a minor nuisance to a hacker since anyone can digitally sign an ActievX control). This is why most security-conscious environments typically disable ActiveX, for example the European Committee for Banking Standards (ECBS) has the following to say in its tech report 401, "Secure Banking over the Internet":

ActiveX, on the other hand, places no restrictions on what a control can do [...] this security model places the responsibility for the computer systems security on the user's end.

On-the-fly downloading of ActiveX controls should be restricted as much as possible. There are significant risks associated with on-the-fly downloading of ActiveX controls. A bank must specifically address the trade-off between functionality and security (if a bank forces its customers to use this technology).

General security concerns regarding ActiveX controls encompass both the safety of the contents and especially the possibility of downloading ActiveX trojan horses. Codesigning only helps to protect the downloading process, it does not address the client PC security issues.

Because of these concerns, some firewalls even provide the ability to automatically filter out all ActiveX controls as a standard features.

This ability to run any software on your machine becomes problematic when used with Microsoft's CryptoAPI, which has a number of known security flaws. The worst one of these is a function called CryptExportKey(), which hands out your private key (that is, your signature-generating token) to anyone who asks for it. Although Microsoft finally fixed this in Internet Explorer (MSIE) 5, the flaw is present in both versions of MSIE which are recommended in the ir-File documentation (3.02 and 4.0). These are the versions which will be installed by default with Windows machines, which means that unless the user explictly goes out and downloads and installs a newer version, they're vulnerable. In addition, although CryptExportKey() was fixed, newer versions of Internet Explorer added newer, different holes which still allow the private key to be stolen (this is useful not only for hackers but also for crypto developers, since it means you can always get at someone's keys on a machine running Microsoft software :-).

Here's how stealing a key with ActiveX would work:

There is a further problem which arises from the way MSIE 3.02 and 4.0 store keys on disk. The encryption used here is very weak, which means it can be broken without too much effort (for more details on this see my writeup and the followup from more than a year ago). Again, although this was finally fixed in MSIE 5.0, the flaw is present in the versions which are installed by default with Windows, which means most users will be running software which contains the problem. Since the encryption isn't hard to break, others can get to your keys, and again you have a reason to dispute the evidence in court.

A lesser concern is that the keys being generated by the browser for use with the digital signatures are almost certainly 512-bit RSA keys, which are generally recognised as offering insufficient security (read any security-related technical specification and you'll see included with it a note to say that these keys shouldn't be used unless you have no other choice. To take two examples, the S/MIME specification says "A user agent SHOULD generate RSA key pairs at a minimum key size of 768 bits [...] 512 bit keys are considered by many to be cryptographically insecure", and the TLS (next-generation SSL) specification says "512-bit RSA keys are not secure enough for high-value transactions or for applications requiring long-term security [...] Because 512-bit RSA keys are relatively insecure, they should be changed often"). In fact there are security guidelines going back nearly a decade which warn against using 512-bit keys - their weakness is the very reason why the US government allows software which uses them to be freely exported.

This offers yet another avenue for disputing the signatures in court. For an appropriate level of security, an RSA key of at least 1024 bits in length should be used, and all of the newer security standards (ANSI X9.30 and X9.31 for digital signatures and encryption, and ANSI X9.42 for key agreement) set their minimum key sizes at 1024 bits. For people wondering why these key sizes seem to bear no relation to "128-bit security", it's because that's merely a (much-misused) marketing term which arises from the way link encryption is implemented in SSL. A 128-bit RSA key which was used for signing data could be broken in seconds on a home PC, the default US-exportable weak encryption uses 512-bit RSA keys, and for real security you should use keys with a minimum of 1024 bits.

To run ir-File, you need to be running Windows

In their Macintosh compatibility technical note, the IRD state that there is a problem with the Macintosh (and, indeed, anything not running Windows) because they won't run Microsoft's CryptoAPI software. Here's an explanation of the IRD's statement:

In order to sign messages, you need access to a private key which is normally generated by the browser and stored in a vendor-specific, proprietary format. Since the IRD aren't using the browser to sign the messages (it's something the browser isn't capable of, you don't have much choice here), they need to access the key themselves and sign the message using their own software. Since Microsoft uses CryptoAPI for the browser, both the browser and the ActiveX control which calls CryptoAPI can read the private key store, so if you're prepared to be completely reliant on Microsoft for everything, this isn't a problem.

Netscape use a different format for their private keys. When the IRD talk about "exporting the key from Netscape and importing it into MSIE", what they're talking about is saving the key from Netscape into a PKCS #12 format file and then reading the file using the Microsoft software and saving it in turn in the CryptoAPI key store - it's a multi-stage translation process designed to take the keys from Netscape and give them to CryptoAPI.

Since the Mac doesn't run CryptoAPI, there's no CryptoAPI key store and therefore no way to get the key into the key store. The whole thing is tied completely to CryptoAPI, so there's no way it can work on anything which isn't running Microsoft's software (it's extremely unlikely that CryptoAPI would run on a Windows emulator because it's hooked so deeply into the Windows kernel that I doubt it'd run in emulation, and this dependency on being hooked into the Windows kernel is a requirement of the US export controls).

Making ir-File technology-independent

Some of the problems mentioned above arise from the fact that ir-File is tied entirely to Microsoft software, which means that it both won't run on anything which doesn't run Windows, and that it stands or falls on the strengh of Microsoft's security (an area in which they have a pretty poor track record). To see why this isn't a good way to do things, let's use the analogy of a Warrant of Fitness for your car. Your car gets tested and, provided the brakes work and the tires aren't bald and a few other checks are passed, you're allowed on the road. In contrast the ir-File approach would be to require that everyone drive a Toyota. If you drive a Toyota, you're allowed on the road; if not, you have 12 months to get rid if your current car and buy one. Needless to say, this isn't making non-Toyota (well, non-Windows) users very happy (disclaimer: This analogy is not intended to imply any similarity between Toyotas and Windows. Toyotas don't crash nearly as often for starters).

A better way to approach the problem would be to choose a non-vendor-specific industry standard for securing submission of returns. Rather than setting the requirements as "Whatever Bill Gates sells us", a more universal solution would be something like "To comply with IRD requirements you must use {PGP or SMIME} signed messages with {assorted key handling and storage requirements}". Both PGP and S/MIME are internationally standardised secure messaging/email formats which are widely available and supported on a large number of platforms (they'll run on anything from MSDOS up to (literally) a Cray supercomputer). Whether PGP or S/MIME is used is mostly a matter of preference, PGP is more widely and freely available but S/MIME is supported by more vendors.

Assigning Blame

It looks like this issue has become a bit of a political hot potato, so I'll reiterate again the comments I've made in other forums: ir-File was prepared within a very tight schedule and budget. In order to do it right, both the time and money sunk into it would have to have been expanded considerably (the IRS electronic filing pilots in the US have been running in various forms for more than two years), which means that instead of the current debate over it being vendor-specific and not capable of providing nonrepudiation, the debate would have been over why it was behind schedule and over budget (as far as I know ir-File was delivered on schedule and within budget, which is a pretty remarkable achievement for a large computer project). Because of this, it's not really fair to try and blame anyone for it - no matter how they approached it, it would have been perceived by someone to be wrong.