could anyone explain to me how the DNSSEC works in a nutshell?
What I can already understand (but i do not know if it is completely correct) is:
DNS is an old protocol created in the early Internet, therefore it has flaws (e.g. no authentication). It allows attacks as Man-In-The-Middle and Cache poisoning.
The solution? The creation of the DNSSEC. A protocol that uses public key cryptography and that gives authentication and integrity to the DNS queries. It works using a chain of trust that starts in the root DNS server - the "trust" here means that you trust in the public key of the root server.
In the zone level, the process works using one or more pair of keys. First the zone server has the ZSK (zone signing key) and it signs the queried data using the private ZSK. After, it sends the public ZSK, the data (RRSET) and the signed data (RRSIG) to the DNS resolver. But now you have to trust in the public ZSK. The solution? To have another key, the KSK (key signing key). The zone signs the new set that contains the public KSK and public ZKS. After it sends that new set, the signed set and the public KSK. It guarantees the security in the zone.
But how about the whole recursive process that the DNS needs? How do we make sure that it is also secure? It is done by making the child server hash its public KSK and sending it to its parent, that stores it as a DS (delegate signature). It is done early and I don't know how. In this way, if you trust the father and the father has the child DS, if you hash the child public KSK and the result be equal to the father DS, you can trust the child. This creates the whole chain of trust. The secure entry point of this chain is in the root. You assume that you can trust in the public key of the root.
This is what I think that I understand about DNSSEC, if someone could explain better, fix what I wrote ou give more information that you think it is essential to understand DNSSEC I would be very grateful.
Also if someone could explain to me the DNSSEC architecture and key management I would be glad as well.
Thank you very much!!!!!
Your question is very broad and not very related to programming.
Like Calle said you are mostly correct already so let me just pinpoint some parts to fix.
First, the important part to remember is that all of this is based on asymetric cryptography: each key is a public and private part. The public part is published in DNSKEY RRs, and also with some hashing in DS records, while the private part is used to compute the RRSIG records. Anyone using the public key would be able to verify that the signatures in the RRSIG records were indeed signed by some specific private key, while never having access to it.
Now on some of your points:
In the zone level, the process works using one or more pair of keys. First the zone server has the ZSK (zone signing key) and it signs the queried data using the private ZSK. After, it sends the public ZSK, the data (RRSET) and the signed data (RRSIG) to the DNS resolver.
At the autoritative nameservers for a given zone, you start with the content of the zone, unsigned. In the old days without DNSSEC this was exactly what was published.
Now you have these three options at least:
an external process takes the zone and signs it; it all depends on how your keys are managed: if they are in an HSM then you need to send the records there to be signed as, by design, the private key (needed to sign records) never leaves the hardware module. See the OpenDNSSEC software for example.
the resolver itself, on loading or through separate tools can sign the zone itself and even manage the keys (as they are changed regularly); see this example in Bind.
or, nothing is signed beforehand, and the resolver will generate (and cache for some time) the RRSIG records at the moment the query arrive.
See how one big provider does it.
Of course, each solution has its advantages and drawbacks. They all exist on the field.
But now you have to trust in the public ZSK. The solution? To have another key, the KSK (key signing key).
The KSK/ZSK split is not really about trust, just key material management.
Let us go back a little. The whole setup of DNSSEC could work theoretically exactly the same way with only one key in each zone.
But in practice it is often more keys.
First, keys need to be changed regularly. There is no specific reason or end of life for them, it is just the assumption that if we want to defend against offline keys cracking we just need to change them regularly. Keys are published without details on their duration (contrary to signatures in RRSIGs) but each DNSSEC signed zone should have a DPS (DNSSEC Practice Statement) that delves, among other things, into the duration of validity for each key (see this other answer of me for more details on DPS).
Of course to prepare for key rollovers, you publish a new key in the DNS in advance, for cache to learn about it, and before starting to sign with it (or at least before stopping to sign with the older one).
So you already can have to handle multiple keys at the same time.
Now you are in the middle of two opposite constraints: you would like to keep using one key for as long as possible to have less handling (and if the key is handled externally the less you have to use it the better it is) since it also exists at the parent zone through the DS record, and as the same time you know that for better security setup you need to use it for a time period as short as possible and renew it often.
You resolve this conendrum by doing a KSK/ZSK split.
Why? Because you can attach different lifetime to each key. The KSK is the one that will also exist in the parent zone through the DS record so typically something that you do not want to change too often. Typically a KSK will be the most secure key (the most protected one) and will "last" for 1 or 2 years (this has to be detailed in the DPS). Then, ZSKs, used for really signing the records in the zone can be keys generated more often, like 1 or 2 months, since changes in them need only to be reflected in the zone itself, there is no need to change anything at the parent zone.
See for example the IANA Root Zone Key ceremony: there is only one root key (absolute trust), and it may change in the future (it was already planned for last October, but then get postponed); anyway twice per year there is a specific key ceremony done in some datacenter and what will exactly happen here? The DNS root zone operator, VeriSign, comes with a specific number of keys (which are the future ZSKs in fact) worth some time (basically until the next ceremony, with some margin, based on the typical ZSKs lifetime as detailed in the relevant DPS), and then the root KSK is properly used, with many witnesses at many levels, to sign those ZSKs. The KSK can then be put back away in storage and never used again (until the next ceremony) and the DNS operator can then start the publish the ZSK, one by one, with their relevant signature.
Again, this is custom but certainly not mandatory. Some zones (like .CO.UK, see how it has only one DNSKEY record) decided to use only one key, and this is called CSK for Common Signing Key, meaning it is at the same time a zone-signing key and a key-signing key (since it signs itself and it is also the one used for the parent DS).
It is done by making the child server hash its public KSK and sending it to its parent, that stores it as a DS (delegate signature). It is done early and I don't know how.
Each zone has to send to its parent, either one (or multiple) KSKs (public part of course) and let the parent compute the relevant DS to publish in its zone, or just send the DS record directly. It is the same problem at each node in the DNS tree, except for the root of course. And the child needs to do that far in advance of using the relevant key to sign anything as he often does not control how much time the parent will take before starting to publish the key.
It is the same of each node in the DNS tree, theoretically because in practice this transfer of information has to be done out-of-band from DNS (except in the CDS/CDNSKEY, see below), and this can be different at each node. It often involves at least some purely human interaction, which explains why the ZSK/KSK split is pleasing, as it lower the frequency with which you need to do anything to replace the KSK.
For example, for TLDs, they need to enter a process at IANA website, to give their new DS records and then wait some time for IANA to process and verify it before it is published in the root zone.
For 2LD (Second Level Domain Names), they typically go to their registrar and through some website or API they provide the information that the registrar will send to the registry so that it can publish it.
Nowadays, the registrar-registry dialogue is made using a protocol called EPP (Extensible Provisioning Protocol) and it has a specific extension for DNSSEC called secDNS.
This extension allows the registrar, on behalf of its client, to send either (based on registry policy):
the DS record (as 4 separate parameters)
the DNSKEY record (as 4 separate parameters), from which the registry will compute itself the appropriate DS record to publish
the DS record with an enclosed (related) DNSKEY record so that the registry can double check if the DS was correctly computed and that it will indeed match some DNSKEY record that the domain has published already
(it is more or less in descending order of frequency of cases on the field).
This solves the provisioning issue. As for nodes lower down the tree you have then less and less standard mechanisms.
There is also another path, this time to use the DNS itself to provision things instead of out-of-band, with the CDS/CDNSKEY records as described in RFC 7344 and RFC 8078. The leading C stands for Child, and then you get again DS or DNSKEY because the core idea is to let a node publish such record in its own zone and then just let the parent zone do DNS queries to pick it up and then provision the parent zone with it.
Of course, this does create some problems at least for the bootstraping.
And these mechanisms are not used too much right now. Specially for the case of DNS hoster not being the registrars themselves, there are various work in progress and ideas so that external parties could influence this and make changes in the parent zone without having to intervene at the EPP level from the registrars to the registry. If you are interested in these topics, please have a look for example at https://www.dk-hostmaster.dk/en/news/cloudflare-integrates-dk-hostmasters-dnssec-setup or https://datatracker.ietf.org/doc/draft-ietf-regext-dnsoperator-to-rrr-protocol/
As for:
Also if someone could explain to me the DNSSEC architecture and key management I would be glad as well.
This is really too broad.
I do not know what you mean by the DNSSEC architecture: there is no one size fits all approach, you will need to at least consider the volume of your zone (number of records to sign), the frequency to which you resign, if not on the fly, and then the associated key rotations, and how and where your keys are stored.
The key management is not any more a point specific to DNSSEC. An X.509 PKI Certificate Authority will have almost the same problems regarding the security of its private key and how it uses it to sign others keys (which would be in fact certificates in this case).
Related
Say a company successfully applied to IANA to make .bob a Top-level domain and the company now operates the registry of every domain with .bob as the TLD. If the comany is under an authoritarian government with a track record of manipulating the Internet infrastructure, can a domain target.bob be hijacked so that it gets resolved to a server the government owns, instead of going through the name server the domain owner specified? Will DNSSEC help?
Yes, technically any node in the DNS tree can pervert everything below. But, especially at the TLD level it will be akin to a move with a nuke, it will be seen quickly and draw lots of actions and consequences.
You may want to go back at the Verisign Sitefinder fiasco. Not exactly the case you describe but very similar. It generated two consequences:
contractually, gTLD registries at least because under contract with ICANN are now prevented to do things like that
technically, there are safeguards, see for example root-delegation-only in bind that means exactly that (for both root and TLDs) to ensure there is no "hijacks".
And DNSSEC can help, but in a limited way. Because in your case even if the domain is properly delegated and DNSSEC secured before the hijack, it means the registry has and published the DS record, so once the hijack happens those DS records can be hijacked as well, or just removed, and end resolvers will see the change but just with that can not detect really a problem nor work around it.
Note that in your case of "authoritarian government" they don't even need to go to the registry and the authoritative nameservers. They can force things at the recursive state also, forcing ISPs. And it completely happens today, and even in non authoritarian government: various names are, by law or judge, forbidden to be resolved. Sometimes it happens at registry side (see Microsoft seizing domains recently - and regularly - at https://arstechnica.com/information-technology/2021/12/microsoft-seizes-domains-used-by-highly-sophisticated-hackers-in-china/), and sometimes at resolver (this the recent judgment against Quad9 a big public recursive nameserver service: https://www.quad9.net/news/blog/quad9-and-sony-music-german-injunction-status/)
Also, side technical note: in the DNS a dot does not mean necessarily a delegation, and both sides can be administratively and technically handled by a single party. For example gouv.fr and fr are technically and administratively handled by the same entity, there is no delegation nor hijack.
I'm developing a solution which stores in a DB, for each customer, an RSA key which will be used to sign payments.
Those keys are so called SIM keys created via an SKS HSM, long story short we don't store actually the key in our DB but only an encrypted blob that only the HSM can use. In this way no one, except the HSM, knows what the keys are.
In order to prevent an inside attacker, with access to the DB, to switch keys among users it was decided to calculate, for each key, an integrity check and store it together with the key.
The solution is to perform an HMAC of customerId + key, in this way it would be impossible to switch keys among users without breaking the integrity check.
The key used to calculate the HMAC is dedicated for this use case and is stored in the HSM. However this point is the one I would like to change and for which I'm making this question.
Technically speaking it would be possible to calculate the integrity check using the RSA key itself by encrypting customerID + key using the public part of the key.
However CTOs are blocking this solution because they said the same key should never be used for signing and encrypting.
In my opinion the guideline to have separate keys for signing and encrypting doesn't apply to this case, in fact the guideline is true but only if we would actually expose an API that perform encryption and signing using the same key, which is not the case. The encryption operation we perform is against data generated by the application itself, not an input, is always the same for the entire lifetime of the key and is used only for the integrity check of the key itself.
I'm looking for someone with security knowledge that can help me understanding if the principle "don't use the same key for signing and encryption" really applies to this case, which in my opinion doesn't.
Thanks a lot.
Your CTO is correct on blocking this. Because you didn't give the details on what kind of payment solution you're building, just the fact you're storing, process and/or transmitting cardholder and/or sensitive authentication data puts you in scope for a PCI-DSS or a PA-DSS audit.
But there are very strict rules for key rotation, strength (you didn't mention the SHA to use with HMAC) and storage when handling sensitive cardholder data.
If you aren't familiar with the PCI Security Council, get ready to learn fast. They publish the guidelines that you as a developer must abide by if you are either developing an in-house solution or one for resale. The first overview are the guidelines themselves:
https://www.pcisecuritystandards.org/pci_security/maintaining_payment_security
As stated above, this forum really is no place to begin to discuss the details of all of the required secure coding practices, network segmentation considerations, employee separation of duties, etc. that are included in complianc = and along with mountains of paperwork and possible quarterly scans. And, based on your size and payment volume, an outside auditor.
In a former position I managed the US, Europe and South America's PCI & PA-DSS software compliance programs and it was very costly. Talk to an expert because you do not want to be the next breach of the day. It sounds like your CTO understands the implications so I'd listen to him.
Ok Advanced SSL gals and guys - I'll be adding a bounty to this after the two-day period as I think it's a complex subject that deserves a reward for anyone who thoughtfully answers.
Some of the assumptions here are simply that: assumptions, or more precisely hopeful guesses. Consider this a brain-teaser, simply saying 'This isn't possible' is missing the point.
Alternative and partial solutions are welcome, personal experience if you've done something 'similar'. I want to learn something from this even if my entire plan is flawed.
Here's the scenario:
I'm developing on an embedded Linux system and want its web server to be able to serve out-of-the-box, no-hassle SSL. Here's the design criteria I'm aiming for:
Must Haves:
I can't have the user add my homegrown CA certificate to their browser
I can't have the user add a statically generated (at mfg time) self-signed certificate to their browser
I can't have the user add a dynamically generated (at boot time) self-signed certificate to their browser.
I can't default to HTTP and have an enable/disable toggle for SSL. It must be SSL.
Both the embedded box and the web browser client may or may not have internet access so must be assumed to function correctly without internet access. The only root CAs we can rely on are the ones shipped with operating system or the browser. Lets pretend that that list is 'basically' the same across browsers and operating systems - i.e. we'll have a ~90% success rate if we rely on them.
I cannot use a fly-by-night operation i.e. 'Fast Eddie's SSL Certificate Clearing House -- with prices this low our servers MUST be hacked!'
Nice to Haves:
I don't want the user warned that the certificate's hostname doesn't match the hostname in the browser. I consider this a nice-to-have because it may be impossible.
Do not want:
I don't want to ship the same set of static keys for each box. Kind of implied by the 'can't' list, but I know the risk.
Yes Yes, I know..
I can and do provide a mechanism for the user to upload their own cert/key but I consider this 'advanced mode' and out of scope of this question. If the user is advanced enough to have their own internal CA or purchase keys then they're awesome and I love them.
Thinking Cap Time
My experience with SSL has been generating cert/keys to be signed by 'real' root, as well as stepping up my game a little bit with making my own internal CA, distributing internally 'self-signed' certs. I know you can chain certificates, but I'm not sure what the order of operations is. i.e. Does the browser 'walk up' the chain see a valid root CA and see that as a valid certificate - or do you need to have verification at every level?
I ran across the description of intermediate certificate authority which got me thinking about potential solutions. I may have gone from 'the simple solution' to 'nightmare mode', but would it be possible to:
Crazy Idea #1
Get an intermediate certificate authority cert signed by a 'real' CA. ( ICA-1 )
ROOT_CA -> ICA-1
This certificate would be used at manufacturing time to generate a unique passwordless sub-intermediate certificate authority pair per box.
ICA-1 -> ICA-2
Use ICA-2 to generate a unique server cert/key. The caveat here is, can you generate a key/pair for an IP (and not a DNS name?)? i.e. A potential use-case for this would be the user connects to the box initially via http, and then redirects the client to the SSL service using the IP in the redirect URL (so that the browser won't complain about mismatches). This could be the card that brings the house down. Since the SSL connection has to be established before any redirects can happen, I can see that also being a problem. But, if that all worked magically
Could I then use the ICA-2 to generate new cert/key pairs any time the box changes IP so that when the web server comes back up it's always got a 'valid' key chain.
ICA-2 -> SP-1
Ok, You're So Smart
Most likely, my convoluted solution won't work - but it'd be great if it did. Have you had a similar problem? What'd you do? What were the trade offs?
Basically, no, you can't do this the way you hope to.
You aren't an intermediate SSL authority, and you can't afford to become one. Even if you were, there's no way in hell you'd be allowed to distribute to consumers everything necessary to create new valid certificates for any domain, trusted by default in all browsers. If this were possible, the entire system would come tumbling down (not that it doesn't already have problems).
You can't generally get the public authorities to sign certificates issued to IP addresses, though there's nothing technically preventing it.
Keep in mind that if you're really distributing the private keys in anything but tamper-proof secured crypto modules, your devices aren't really secured by SSL. Anyone who has one of the devices can pull the private key (especially if it's passwordless) and do valid, signed, MITM attacks on all your devices. You discourage casual eavesdropping, but that's about it.
Your best option is probably to get and sign certificates for a valid internet subdomain, and then get the device to answer for that subdomain. If it's a network device in the outgoing path, you can probably do some routing magic to make it answer for the domain, similarly to how many walled-garden systems work. You could have something like "system432397652.example.com" for each system, and then generate a key for each box that corresponds to that subdomain. Have direct IP access redirect to the domain, and either have the box intercept the request, or do some DNS trickery on the internet so that the domain resolves to the correct internal IP for each client. Use a single-purpose host domain for that, don't share with your other business websites.
Paying more for certificates doesn't really make them any more or less legit. By the time a company has become a root CA, it's far from a fly-by-night operation. You should check and see if StartSSL is right for your needs, since they don't charge on a per-certificate basis.
I'd like to uniquely identify users by issuing security tokens to them. In order to guarantee non-repudiation I'd like to ensure that no one has access to the user's private key, not even the person who issues the tokens.
What's the cheapest/most-secure way to implement this?
Use a 3rd party certificate authority: you don't know the private key and you don't have to care about how the client gets and secures the private key (but you can worry about it). Not the cheapest solution ever...
OR:
Share a secret with each client (printed on paper, through email, phone, whatever...).
Have the client generate the keys based on that secret, time (lets say 5 minute intervals) and whatever else you can get (computer hardware id - if you already know it, client IP, etc...). Make sure that you have the user input the secret and never store it in an app/browser.
Invalidate/expire the tokens often and negotiate new ones
This is only somewhat safe (just like any other solution)...if you want to be safe, make sure that the client computer is not compromised.
It depends on where/how you want to use those keys* but the bottom line is that in the case of asymmetric keys, the client will encrypt the data sent to you (the server) using their private key and you (the server) will decrypt that data using the client's public key (opposite of how HTTPS works).
Can you verify, at any point in time, the identity of your clients?
If the client computer is compromised, you can safely assume that the private key is compromised too. What's wrong with SSL/HTTPS. Do you really need to have one certificate per client?
Tokens are not the same thing as keys and they don't have to rely on public/private keys. Transport, however, might require encryption.
*my bank gave me a certificate (which only works in IE) used to access my online banking account. I had to go through several convoluted steps to generate and install that certificate and it only works on one computer - do you think that your clients/users would agree to go through this kind of setup?
It would be relatively easy for compromised computers to steal the user's private key if it were stored as a soft public key (e.g., on the hard drive). (APT (botnet) malware has been known to include functionality to do exactly this.)
But more fundamentally, nothing short of physically incapacitating the user will guarantee non-repudiation. Non-repudiation is something the user chooses to do, opposing evidence notwithstanding, and to prove that a user didn't do something is impossible. Ultimately, non-repudiation involves a legal (or at least a business) question: what level of confidence do you have that the user performed the action he is denying having performed and that his denial is dishonest? Cryptosystems can only provide reasonable confidence of a user's involvement in an action; they cannot provide absolute proof.
PIV cards (and PIV-I cards) use a number of safeguards for signing certificates. First, the private key is stored on the smart card, and there is no trivial way to extract it. The card requires a numeric PIN to use the private signing key, and effectively destroys the key after a certain number of incorrect attempts. The hardware cryptomodule must meet Level-2 standards and be tamper-resistant, and transport of the card requires Level-3 physical security (FIPS 201). The certificate is signed by a trusted CA. The PIN, if entered using a keyboard, must be sent directly to the card to avoid keylogger-type attacks.
These precautions are elaborate, intensive, and still do not guarantee non-repudiation. (What if malware convinces the user to sign a different document than the one he is intending to sign? Or the user is under duress? Or an intelligence agency obtains the card in transit and uses a secret vulnerability to extract the private key before replacing the card?)
Security is not generally a question of cheapest/most secure, but rather of risk assessment, mitigation, and ultimately acceptance. What are your significant risks? If you assess the types of non-repudiation risks you face and implement effective compensating controls, you will be more likely to find a cost-effective solution than if you seek to eliminate risk altogether.
The standard way to handle non-repudiation in a digital signature app is to use a trusted third party, a 3rd party cert authority.
Be careful trying to create your own system--since you're not an expert in the field, you'll most probably end up either losing the non-repudiation ability that you seek or some other flaw.
The reason the standards for digital signatures exist is that this stuff is very hard to get right in a provable way. See "Schneier's Law"
Also, eventually, non-repudiation comes down to someone being sued--you say that "B" did it (signed the agreement, pressed the button, etc), but "B" denies it. You say you can "prove" that B did it. But so what, you'll need to prove in court that B did it, to get the court to grant you relief (to order B to do something such as pay damages.)
But it will be very very expensive to sue someone and to prove their case due to a digital sig system. And if you went to all that trouble and then the digital sig system was some homebrew system, not a standard, then your odds of relief would drop down to about 0%.
Conclusion: if you care enough about the digital sig to sue people, then use a standard for digital sig. If you will ultimately negotiate rather than sue, then look at the different options.
For example, why not use a hardware security token They're now available as apps for people's phones, too.
I am building an application that will enable users to connect to the same server. Rather than the application/device using its own certificate/private key, it is important to ensure that each user has their own certificate/private key to use for encryption.
Now I know, from the OpenSSL website documents, that their internal certificate store of OpenSSL can hold one certificate/key pair for the RSA cipher. My question is this:
Presume I have a SSL struct named ssl1 that I created from my SSL_CTX where I didn't set the certificate/key to use in the SSL_CTX (thus not inheriting the certificate/key). I then go on to set the certificate/key for ssl1 that is associated with some user. Then suppose I have another SSL struct named ssl2 created from the same SSL_CTX. I then go on to set the certificate/key for ssl2 that is associated with a different user than the first one.
If at this point I call the SSL_connect() API on ssl1 will it use the certificate/key I set for ssl2? I ask since the store says it only holds one cert/key pair and I loaded the cert/key for ssl2 last, thus I presume it would overwrite the one I loaded first for ssl1.
Thanks for reading my post. I appreciate any help/wisdom/pointers you can provide.
As far as I understand the SSL_CTX acts as template for SSL objects. So when you create new SSL object it inherits the properties/attributes of the SSL_CTX from which it is created. This is clearly mentioned here
So for your question, both ssl1 and ssl2 objects will use their own certificate/key.
First, I'm confused about the implementation details you're asking for. Second, I can't think of a circumstance in which different keys would be useful unless you're trying to authenticate your users by their certificates -- which you're apparently not doing (users needing different encryption, not authentication.
I believe what you really want to do is establish your connections using settings that provide for Perfect Forward Secrecy. To do that, you want to use TLS ciphers all have names that start with TLS_DHE_. Those use Diffie-Hellman key exchanges, thus making the role of the server's key basically one of authentication of the server to users.