4 ms·

I have been designing cryptographic protocols for securing card payment transactions, card data and pins. I then was going with those systems through stringent

I have been designing cryptographic protocols for securing card payment transactions, card data and pins. I then was going with those systems through stringent certifications from various organizations, especially PCI. Not enforcing signatures when exchanging keys? Is this crypto-kindergarten? With a well designed payment system it is expected that the attackers have access to basically all of infrastructure -- servers, databases holding keys, network, disassemble terminals, bribe employees, etc. and still have no chance injecting their own keys, read pins or get any cryptographic material of value. Why can't you just guys who pretend to build secure system spend some times reading real requirements from PCI or Visa or Mastercard to get at least some idea how real secure systems are built in at least one area?

schoen 8y ago
I suppose that in the payment systems, there's a trusted party that has the ability to compromise transactions. The different parties in the system trust that party and rely on audit and potentially arbitration or litigation to resolve disputes about individual transactions or classes of transactions. For end-to-end encryption for messaging applications, there may not be any such entity that everyone can trust. In that case, there needs to be a solution for key exchange to allow new parties and devices to join the system. In payments you could presumably say "the banks/banking association/cryptographic contractor of the banking association is the authority that certifies new entities that join the system". In messaging you probably can't do that if you're concerned that law enforcement will force that entity to add false certifications! In other words, I think you're referring to a cryptographic problem with a somewhat different threat model.
- lmilcin 8y ago
  There don't and should not be any trusted parties. Every trusted party is, by definition, a point of failure if the party is compromised. PCI requires that organizations control cryptographic material using rules of dual control and split knowledge. No individual should have access to entire cryptographic key and any processes and devices should require at least two people to operate. For example, HSM-s are ALWAYS operated by at least two security officers. Cryptographic keys are generated by HSM in the form of multiple components onto multiple smartcards. Each smartcard is stored in a separate safe where only the security officer/s assigned to that component have access. The HSM to be injected with keys must be operated by multiple security officers with their components. The HSM is regularly inspected -- each security officer brings his key from his safe, two keys are required to open the enclosure where the HSM is located. When the payment terminal is injected with keys there are two operators present monitoring each other to prevent tampering with the process. Etc. With good understanding of the concepts it is possible to build secure system. It's not that hard.
  - schoen 8y ago
    I think we're talking about different levels of the system. The attack in this case was not about an individual employee unilaterally taking an improper action, but about a company being officially compelled by a government to take an action that was contrary to the interest of an end-user. In the financial system this happens all the time and is considered somewhat unremarkable. If this company had had a dual control mechanism where multiple security officers had to be involved in order to issue signatures, presumably the company's executives would have told those security officers "we have to issue this signature because the government requires us to", and presumably the security officers would then have done it. It wasn't a rogue action from the organizational point of view, only from the customer's point of view. Also, in a messaging application new public keys have to be certified extremely frequently because new users and devices are constantly joining the system with new keys. Presumably this happens in an automated online fashion (otherwise, the security officers aren't going to get much sleep). That makes it even more challenging to subdivide the responsibility for certification, for many reasons. I don't mean to disparage the precautions that financial organizations have implemented, and I agree that some parts of the software world sometimes seem extremely cavalier in comparison. But I still think that in this particular case the threat models are extremely different.
    - lmilcin 8y ago
      Nope, not really. 1. They are choosing and then providing devices. This is very important because it means they have physical contact with the device, initially, so they have means to bootstrap cryptographic system by way of injecting keys, etc. 2. They are middlemen transferring messages between multiple parties that use their devices without having to understand the secret part of the message and only routing the messages. 3. They are paid well enough for the service that they should be able to cover expensive devices and processes like manual key injection or expensive hardware security modules. 4. The core of the business is security, if it is not provided nothing else will change the fact they have not provided what they were paid for. The only real difference from payment industry is that the threat is from governments, too.
      - 8y ago
motohagiography 8y ago
You'd think, but as I remember even the EMV specs can be a bit handwavy about the entropy of derivation components, and the tendency to rely on both limited attempts in hardware, and the security of keys generated and stored in HSMs (which people essentially use hashicorp to replace these days), the attack surface is fairly broad for a police service. There is a basic bootstrapping problem with all these systems, where either you have a TSM facility of some sort, or you accept the ostensibly very low likelihood that your key provisioning protocol gets compromised. Trouble is, if you are a target of any intelligence interest, any linux remote zero day means your provisioning server is probably going to get owned out of the gate as soon as someone seizes one of your devices. Not checking a signature seems like an unforced error, but really, there are so many plausible ways this could have happened.
- lmilcin 8y ago
  Bootstrapping can be done correctly, but it requires a lot of planning and preparation to do right. We had to scrap few attempts at bootstrapping. For example, we had to scrap our first attempt because we have allowed single employee to receive the package with the HSM. The security of well designed system will not be impacted by any number of zero-days or attackers having free access to your network, devices, databases, etc. This is because well designed system will not base security of the data it protects on components and mechanisms that cannot be trusted to be secure.
  - motohagiography 8y ago
    Really depends on your threat model. If it includes international police and intelligence agencies, a COTS HSM seems optimistic.

schoen 8y ago

I suppose that in the payment systems, there's a trusted party that has the ability to compromise transactions. The different parties in the system trust that party and rely on audit and potentially arbitration or litigation to resolve disputes about individual transactions or classes of transactions. For end-to-end encryption for messaging applications, there may not be any such entity that everyone can trust. In that case, there needs to be a solution for key exchange to allow new parties and devices to join the system. In payments you could presumably say "the banks/banking association/cryptographic contractor of the banking association is the authority that certifies new entities that join the system". In messaging you probably can't do that if you're concerned that law enforcement will force that entity to add false certifications! In other words, I think you're referring to a cryptographic problem with a somewhat different threat model.

lmilcin 8y ago
There don't and should not be any trusted parties. Every trusted party is, by definition, a point of failure if the party is compromised. PCI requires that organizations control cryptographic material using rules of dual control and split knowledge. No individual should have access to entire cryptographic key and any processes and devices should require at least two people to operate. For example, HSM-s are ALWAYS operated by at least two security officers. Cryptographic keys are generated by HSM in the form of multiple components onto multiple smartcards. Each smartcard is stored in a separate safe where only the security officer/s assigned to that component have access. The HSM to be injected with keys must be operated by multiple security officers with their components. The HSM is regularly inspected -- each security officer brings his key from his safe, two keys are required to open the enclosure where the HSM is located. When the payment terminal is injected with keys there are two operators present monitoring each other to prevent tampering with the process. Etc. With good understanding of the concepts it is possible to build secure system. It's not that hard.
- schoen 8y ago
  I think we're talking about different levels of the system. The attack in this case was not about an individual employee unilaterally taking an improper action, but about a company being officially compelled by a government to take an action that was contrary to the interest of an end-user. In the financial system this happens all the time and is considered somewhat unremarkable. If this company had had a dual control mechanism where multiple security officers had to be involved in order to issue signatures, presumably the company's executives would have told those security officers "we have to issue this signature because the government requires us to", and presumably the security officers would then have done it. It wasn't a rogue action from the organizational point of view, only from the customer's point of view. Also, in a messaging application new public keys have to be certified extremely frequently because new users and devices are constantly joining the system with new keys. Presumably this happens in an automated online fashion (otherwise, the security officers aren't going to get much sleep). That makes it even more challenging to subdivide the responsibility for certification, for many reasons. I don't mean to disparage the precautions that financial organizations have implemented, and I agree that some parts of the software world sometimes seem extremely cavalier in comparison. But I still think that in this particular case the threat models are extremely different.
  - lmilcin 8y ago
    Nope, not really. 1. They are choosing and then providing devices. This is very important because it means they have physical contact with the device, initially, so they have means to bootstrap cryptographic system by way of injecting keys, etc. 2. They are middlemen transferring messages between multiple parties that use their devices without having to understand the secret part of the message and only routing the messages. 3. They are paid well enough for the service that they should be able to cover expensive devices and processes like manual key injection or expensive hardware security modules. 4. The core of the business is security, if it is not provided nothing else will change the fact they have not provided what they were paid for. The only real difference from payment industry is that the threat is from governments, too.
    - 8y ago

motohagiography 8y ago

You'd think, but as I remember even the EMV specs can be a bit handwavy about the entropy of derivation components, and the tendency to rely on both limited attempts in hardware, and the security of keys generated and stored in HSMs (which people essentially use hashicorp to replace these days), the attack surface is fairly broad for a police service. There is a basic bootstrapping problem with all these systems, where either you have a TSM facility of some sort, or you accept the ostensibly very low likelihood that your key provisioning protocol gets compromised. Trouble is, if you are a target of any intelligence interest, any linux remote zero day means your provisioning server is probably going to get owned out of the gate as soon as someone seizes one of your devices. Not checking a signature seems like an unforced error, but really, there are so many plausible ways this could have happened.

lmilcin 8y ago
Bootstrapping can be done correctly, but it requires a lot of planning and preparation to do right. We had to scrap few attempts at bootstrapping. For example, we had to scrap our first attempt because we have allowed single employee to receive the package with the HSM. The security of well designed system will not be impacted by any number of zero-days or attackers having free access to your network, devices, databases, etc. This is because well designed system will not base security of the data it protects on components and mechanisms that cannot be trusted to be secure.
- motohagiography 8y ago
  Really depends on your threat model. If it includes international police and intelligence agencies, a COTS HSM seems optimistic.