New crypto accelerator/HSM development
Hi Is there anyone out there, academics perhaps, developing new crypto accelerator/HSM hardware with a focus on high performance (e.g. 10k+ RSA sigs per second)? The current market is pretty poor with largely over-priced and under-performing kit and I'm hoping that someone is plotting to revolutionise it with something new and looking for a partner. cheers Jay -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
There has been some work on doing crypto acceleration on GPUs recently, mainly SSL which is not quite what you are looking for I guess. http://shader.kaist.edu/sslshader/ Richard. On 05/04/11 09:50, Jay Daley wrote:
Hi
Is there anyone out there, academics perhaps, developing new crypto accelerator/HSM hardware with a focus on high performance (e.g. 10k+ RSA sigs per second)? The current market is pretty poor with largely over-priced and under-performing kit and I'm hoping that someone is plotting to revolutionise it with something new and looking for a partner.
cheers Jay
Useful but no HSM functionality. The .cz (Czech Republic) folks did some work on this too: https://www.dns-oarc.net/files/workshop-201103/OndrejSury-DNSSEC-20110313-OS... Jay On 5/04/2011, at 10:13 AM, Richard Nelson wrote:
There has been some work on doing crypto acceleration on GPUs recently, mainly SSL which is not quite what you are looking for I guess.
http://shader.kaist.edu/sslshader/
Richard.
On 05/04/11 09:50, Jay Daley wrote:
Hi
Is there anyone out there, academics perhaps, developing new crypto accelerator/HSM hardware with a focus on high performance (e.g. 10k+ RSA sigs per second)? The current market is pretty poor with largely over-priced and under-performing kit and I'm hoping that someone is plotting to revolutionise it with something new and looking for a partner.
cheers Jay
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
The HSM space seems to be very tightly controlled. We've been looking for affordable solutions for PIN block decryption for our payments work and the options seem to be very limited (and expensive and slow). We've asked around in the payments space here and in Australia and the answer is always 'buy an HSM from one of these two places' and for attaining more throughput it is invariably 'buy more HSMs'. I think they like it being a black box solution, that way they can claim it's secure. If you do find anything I would be very interested in getting the details from you. Cheers, Gerard On 5/04/2011 10:13 a.m., Richard Nelson wrote:
There has been some work on doing crypto acceleration on GPUs recently, mainly SSL which is not quite what you are looking for I guess.
http://shader.kaist.edu/sslshader/
Richard.
On 05/04/11 09:50, Jay Daley wrote:
Hi
Is there anyone out there, academics perhaps, developing new crypto accelerator/HSM hardware with a focus on high performance (e.g. 10k+ RSA sigs per second)? The current market is pretty poor with largely over-priced and under-performing kit and I'm hoping that someone is plotting to revolutionise it with something new and looking for a partner.
cheers Jay
Or if you don't actually need a hardware solution, you could run up an HSM simulator (like http://thalessim.codeplex.com/) on faster gear than the real HSM has and get performance that way. On 5/04/2011 10:22 a.m., Gerard Creamer wrote:
The HSM space seems to be very tightly controlled. We've been looking for affordable solutions for PIN block decryption for our payments work and the options seem to be very limited (and expensive and slow). We've asked around in the payments space here and in Australia and the answer is always 'buy an HSM from one of these two places' and for attaining more throughput it is invariably 'buy more HSMs'. I think they like it being a black box solution, that way they can claim it's secure.
If you do find anything I would be very interested in getting the details from you.
Cheers, Gerard
On 5/04/2011 10:13 a.m., Richard Nelson wrote:
There has been some work on doing crypto acceleration on GPUs recently, mainly SSL which is not quite what you are looking for I guess.
http://shader.kaist.edu/sslshader/
Richard.
On 05/04/11 09:50, Jay Daley wrote:
Hi
Is there anyone out there, academics perhaps, developing new crypto accelerator/HSM hardware with a focus on high performance (e.g. 10k+ RSA sigs per second)? The current market is pretty poor with largely over-priced and under-performing kit and I'm hoping that someone is plotting to revolutionise it with something new and looking for a partner.
cheers Jay
_______________________________________________
A software HSM can normally only do around 5k - 6k 1024 RSA sigs per second: http://trac.opendnssec.org/wiki/SoftHSM/Performance I want multiple cards in a machine to do 40k+ Jay On 5/04/2011, at 10:37 AM, Gerard Creamer wrote:
Or if you don't actually need a hardware solution, you could run up an HSM simulator (like http://thalessim.codeplex.com/) on faster gear than the real HSM has and get performance that way.
On 5/04/2011 10:22 a.m., Gerard Creamer wrote:
The HSM space seems to be very tightly controlled. We've been looking for affordable solutions for PIN block decryption for our payments work and the options seem to be very limited (and expensive and slow). We've asked around in the payments space here and in Australia and the answer is always 'buy an HSM from one of these two places' and for attaining more throughput it is invariably 'buy more HSMs'. I think they like it being a black box solution, that way they can claim it's secure.
If you do find anything I would be very interested in getting the details from you.
Cheers, Gerard
On 5/04/2011 10:13 a.m., Richard Nelson wrote:
There has been some work on doing crypto acceleration on GPUs recently, mainly SSL which is not quite what you are looking for I guess.
http://shader.kaist.edu/sslshader/
Richard.
On 05/04/11 09:50, Jay Daley wrote:
Hi
Is there anyone out there, academics perhaps, developing new crypto accelerator/HSM hardware with a focus on high performance (e.g. 10k+ RSA sigs per second)? The current market is pretty poor with largely over-priced and under-performing kit and I'm hoping that someone is plotting to revolutionise it with something new and looking for a partner.
cheers Jay
_______________________________________________
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
Hi Jay, Your question here well and truly distracted me for a while - have played with both RSA and hardware design in FPGAs before but hadn't thought of combining. After looking in to it, the reality is that RSA signing is insanely expensive - IMHO already about as cheap as it's going to get any time soon. A single 1024 bit signature requires an average of 1536 1024x1024-bit multiplications, up to 2048 if using path-independent code to prevent timing attacks. A 1024x1024 multiplication can be built up by accumulating the result of 1024 32x32 bit multiplications. That load can be divided between a number of multiplication units, but we're still talking 1,572,864 32-bit multiplications per signature. That's even before you add the modulo operation at the end of each of the 1024 bit multiplications. Tried to work out how much I could get out of an FPGA here. The one I have could probably handle about 150 signatures/second with its multipliers assuming optimal conditions. Top of the line FPGAs could do 5000 or so in a $1.5k acceleration card. HSMs are expensive for a reason. $5k a unit entirely reasonable for that sort of specialised hardware. If much more than that, you should start asking questions. Cheers, Tim On Tuesday 05 April 2011 09:50:00 Jay Daley wrote:
Hi
Is there anyone out there, academics perhaps, developing new crypto accelerator/HSM hardware with a focus on high performance (e.g. 10k+ RSA sigs per second)? The current market is pretty poor with largely over-priced and under-performing kit and I'm hoping that someone is plotting to revolutionise it with something new and looking for a partner.
cheers Jay
Hi Tim On 6/04/2011, at 12:41 PM, Timothy Goddard wrote:
Hi Jay,
Your question here well and truly distracted me for a while - have played with both RSA and hardware design in FPGAs before but hadn't thought of combining. After looking in to it, the reality is that RSA signing is insanely expensive - IMHO already about as cheap as it's going to get any time soon.
A single 1024 bit signature requires an average of 1536 1024x1024-bit multiplications, up to 2048 if using path-independent code to prevent timing attacks. A 1024x1024 multiplication can be built up by accumulating the result of 1024 32x32 bit multiplications. That load can be divided between a number of multiplication units, but we're still talking 1,572,864 32-bit multiplications per signature. That's even before you add the modulo operation at the end of each of the 1024 bit multiplications.
Tried to work out how much I could get out of an FPGA here. The one I have could probably handle about 150 signatures/second with its multipliers assuming optimal conditions. Top of the line FPGAs could do 5000 or so in a $1.5k acceleration card.
Absolutely fascinating. I'll talk more offline about that.
HSMs are expensive for a reason. $5k a unit entirely reasonable for that sort of specialised hardware. If much more than that, you should start asking questions.
Basic models start at around $15k and some suppliers go well north of that. ta Jay
Cheers,
Tim
On Tuesday 05 April 2011 09:50:00 Jay Daley wrote:
Hi
Is there anyone out there, academics perhaps, developing new crypto accelerator/HSM hardware with a focus on high performance (e.g. 10k+ RSA sigs per second)? The current market is pretty poor with largely over-priced and under-performing kit and I'm hoping that someone is plotting to revolutionise it with something new and looking for a partner.
cheers Jay
-- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
On 2011-04-05, at 21:34, Jay Daley wrote:
HSMs are expensive for a reason. $5k a unit entirely reasonable for that sort of specialised hardware. If much more than that, you should start asking questions.
Basic models start at around $15k and some suppliers go well north of that.
I've seen top-of-the-line, FIPS140-2 class 4-certified devices new for around USD 10k (and these are not devices you want to buy used, unless you get them reconditioned by a vendor, since you lose a documented chain of custody for the hardware which can make any tiered security policy built above it look like a waste of time). I realise you're talking about RSA performance here, but there is a good deal of knee-jerk "we need an HSM for security reasons" folklore spreading around the DNS community that I think needs to be damped down. DNSSEC signatures, as deployed by most people, have relatively short lifetimes (of the order of a week). This implies regular, automated re-signing of individual RRSets, which in turn implies an HSM which is on-line without requiring manual activation, at least for the ZSK. Some signer packages, e.g. OpenDNSSEC, don't support off-line KSK operation so in that case your KSK is on-line too. Hence, anybody who compromises your signers potentially has full ability to generate signatures using genuine keys. They don't have the ability to run off with the private key materials, but there are plenty of attack vectors where the ability to generate genuine signatures over bogus RRSets is sufficient (and in case of key compromise you can roll your ZSK on a sixpence anyway, and even the process through ICANN, NTIA and VeriSign to roll a DS RRSet in the root zone can be done in 48 hours). HSMs have their place, but I think it's a mistake to assume that they are necessary in order to maintain adequate security. An appropriate security policy involves a thorough threat analysis, and the results of that analysis might not always hinge on the use of cryptographic modules to store private keys -- in fact, the needless use of HSMs means greater operational complexity, additional hardware support burden, additional compatibility concerns and consequently reduced reliability. Security without reliability doesn't make much sense. With respect to performance, I think the realistic approach for provisioning purposes is to bear in mind that (a) even TLDs with extensive registrar/registrant DNSSEC uptake like CZ still don't see very high proportions of secure vs. insecure delegations, (b) insecure delegations (NS RRSets and associated glue) aren't signed in the parent zone, so zone size matters less than the number of secure delegations, (c) NSEC3 with opt-out avoids the signature burden of NSEC records, again scaling linearly with DNSSEC uptake by registrants, and (d) you can manage the signature load by imposing jitter on individual signature inception and expiry times to avoid having to do wholesale re-signing of the whole zone except in times of unusual system failure, at which point most bets are off anyway. Choosing crypto (accelerator) modules based on required performance to do a complete re-sign of the projected zone size in 5 years assuming 100% secure delegations might well serve no better in practice than a vastly lower-spec solution, given the rarity of that scenario. Joe
Hi Joe On 7/04/2011, at 1:33 AM, Joe Abley wrote:
I've seen top-of-the-line, FIPS140-2 class 4-certified devices new for around USD 10k (and these are not devices you want to buy used, unless you get them reconditioned by a vendor, since you lose a documented chain of custody for the hardware which can make any tiered security policy built above it look like a waste of time).
I realise you're talking about RSA performance here, but there is a good deal of knee-jerk "we need an HSM for security reasons" folklore spreading around the DNS community that I think needs to be damped down.
DNSSEC signatures, as deployed by most people, have relatively short lifetimes (of the order of a week). This implies regular, automated re-signing of individual RRSets, which in turn implies an HSM which is on-line without requiring manual activation, at least for the ZSK. Some signer packages, e.g. OpenDNSSEC, don't support off-line KSK operation so in that case your KSK is on-line too.
Hence, anybody who compromises your signers potentially has full ability to generate signatures using genuine keys. They don't have the ability to run off with the private key materials, but there are plenty of attack vectors where the ability to generate genuine signatures over bogus RRSets is sufficient (and in case of key compromise you can roll your ZSK on a sixpence anyway, and even the process through ICANN, NTIA and VeriSign to roll a DS RRSet in the root zone can be done in 48 hours).
HSMs have their place, but I think it's a mistake to assume that they are necessary in order to maintain adequate security. An appropriate security policy involves a thorough threat analysis, and the results of that analysis might not always hinge on the use of cryptographic modules to store private keys -- in fact, the needless use of HSMs means greater operational complexity, additional hardware support burden, additional compatibility concerns and consequently reduced reliability. Security without reliability doesn't make much sense.
With respect to performance, I think the realistic approach for provisioning purposes is to bear in mind that (a) even TLDs with extensive registrar/registrant DNSSEC uptake like CZ still don't see very high proportions of secure vs. insecure delegations, (b) insecure delegations (NS RRSets and associated glue) aren't signed in the parent zone, so zone size matters less than the number of secure delegations, (c) NSEC3 with opt-out avoids the signature burden of NSEC records, again scaling linearly with DNSSEC uptake by registrants, and (d) you can manage the signature load by imposing jitter on individual signature inception and expiry times to avoid having to do wholesale re-signing of the whole zone except in times of unusual system failure, at which point most bets are off anyway.
Choosing crypto (accelerator) modules based on required performance to do a complete re-sign of the projected zone size in 5 years assuming 100% secure delegations might well serve no better in practice than a vastly lower-spec solution, given the rarity of that scenario.
Sigh. I'm well aware of all of the above and don't need online patronising about it. It is after all what I do for a living. My question is not really about .nz since we have our signers, but about what kit will be available for registrars, hosting companies and enterprises as they come to rollout DNSSEC. They will have authoritative data, lots of it and will need the performance. They will also have a wide variety of internal security requirements so that some will need plain accelerators and some HSMs. For DNSSEC to be a success, registries need to be supporting their customers in many ways and not just thinking of their own requirements. Jay
Joe
-- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
Looks like the top of the latest Nitrox processors does up to 200k RSA/s . http://www.caviumnetworks.com/processor_security_nitrox-III.html On Thursday 07 April 2011 07:04:01 Jay Daley wrote:
Hi Joe
On 7/04/2011, at 1:33 AM, Joe Abley wrote:
I've seen top-of-the-line, FIPS140-2 class 4-certified devices new for around USD 10k (and these are not devices you want to buy used, unless you get them reconditioned by a vendor, since you lose a documented chain of custody for the hardware which can make any tiered security policy built above it look like a waste of time).
I realise you're talking about RSA performance here, but there is a good deal of knee-jerk "we need an HSM for security reasons" folklore spreading around the DNS community that I think needs to be damped down.
DNSSEC signatures, as deployed by most people, have relatively short lifetimes (of the order of a week). This implies regular, automated re-signing of individual RRSets, which in turn implies an HSM which is on-line without requiring manual activation, at least for the ZSK. Some signer packages, e.g. OpenDNSSEC, don't support off-line KSK operation so in that case your KSK is on-line too.
Hence, anybody who compromises your signers potentially has full ability to generate signatures using genuine keys. They don't have the ability to run off with the private key materials, but there are plenty of attack vectors where the ability to generate genuine signatures over bogus RRSets is sufficient (and in case of key compromise you can roll your ZSK on a sixpence anyway, and even the process through ICANN, NTIA and VeriSign to roll a DS RRSet in the root zone can be done in 48 hours).
HSMs have their place, but I think it's a mistake to assume that they are necessary in order to maintain adequate security. An appropriate security policy involves a thorough threat analysis, and the results of that analysis might not always hinge on the use of cryptographic modules to store private keys -- in fact, the needless use of HSMs means greater operational complexity, additional hardware support burden, additional compatibility concerns and consequently reduced reliability. Security without reliability doesn't make much sense.
With respect to performance, I think the realistic approach for provisioning purposes is to bear in mind that (a) even TLDs with extensive registrar/registrant DNSSEC uptake like CZ still don't see very high proportions of secure vs. insecure delegations, (b) insecure delegations (NS RRSets and associated glue) aren't signed in the parent zone, so zone size matters less than the number of secure delegations, (c) NSEC3 with opt-out avoids the signature burden of NSEC records, again scaling linearly with DNSSEC uptake by registrants, and (d) you can manage the signature load by imposing jitter on individual signature inception and expiry times to avoid having to do wholesale re-signing of the whole zone except in times of unusual system failure, at which point most bets are off anyway.
Choosing crypto (accelerator) modules based on required performance to do a complete re-sign of the projected zone size in 5 years assuming 100% secure delegations might well serve no better in practice than a vastly lower-spec solution, given the rarity of that scenario.
Sigh. I'm well aware of all of the above and don't need online patronising about it. It is after all what I do for a living.
My question is not really about .nz since we have our signers, but about what kit will be available for registrars, hosting companies and enterprises as they come to rollout DNSSEC. They will have authoritative data, lots of it and will need the performance. They will also have a wide variety of internal security requirements so that some will need plain accelerators and some HSMs. For DNSSEC to be a success, registries need to be supporting their customers in many ways and not just thinking of their own requirements.
Jay
Joe
On 7/04/2011, at 7:04 AM, Jay Daley wrote:
Hi Joe
On 7/04/2011, at 1:33 AM, Joe Abley wrote:
I've seen top-of-the-line, FIPS140-2 class 4-certified devices new for around USD 10k (and these are not devices you want to buy used, unless you get them reconditioned by a vendor, since you lose a documented chain of custody for the hardware which can make any tiered security policy built above it look like a waste of time).
I realise you're talking about RSA performance here, but there is a good deal of knee-jerk "we need an HSM for security reasons" folklore spreading around the DNS community that I think needs to be damped down.
DNSSEC signatures, as deployed by most people, have relatively short lifetimes (of the order of a week). This implies regular, automated re-signing of individual RRSets, which in turn implies an HSM which is on-line without requiring manual activation, at least for the ZSK. Some signer packages, e.g. OpenDNSSEC, don't support off-line KSK operation so in that case your KSK is on-line too.
Hence, anybody who compromises your signers potentially has full ability to generate signatures using genuine keys. They don't have the ability to run off with the private key materials, but there are plenty of attack vectors where the ability to generate genuine signatures over bogus RRSets is sufficient (and in case of key compromise you can roll your ZSK on a sixpence anyway, and even the process through ICANN, NTIA and VeriSign to roll a DS RRSet in the root zone can be done in 48 hours).
HSMs have their place, but I think it's a mistake to assume that they are necessary in order to maintain adequate security. An appropriate security policy involves a thorough threat analysis, and the results of that analysis might not always hinge on the use of cryptographic modules to store private keys -- in fact, the needless use of HSMs means greater operational complexity, additional hardware support burden, additional compatibility concerns and consequently reduced reliability. Security without reliability doesn't make much sense.
With respect to performance, I think the realistic approach for provisioning purposes is to bear in mind that (a) even TLDs with extensive registrar/registrant DNSSEC uptake like CZ still don't see very high proportions of secure vs. insecure delegations, (b) insecure delegations (NS RRSets and associated glue) aren't signed in the parent zone, so zone size matters less than the number of secure delegations, (c) NSEC3 with opt-out avoids the signature burden of NSEC records, again scaling linearly with DNSSEC uptake by registrants, and (d) you can manage the signature load by imposing jitter on individual signature inception and expiry times to avoid having to do wholesale re-signing of the whole zone except in times of unusual system failure, at which point most bets are off anyway.
Choosing crypto (accelerator) modules based on required performance to do a complete re-sign of the projected zone size in 5 years assuming 100% secure delegations might well serve no better in practice than a vastly lower-spec solution, given the rarity of that scenario.
Sigh. I'm well aware of all of the above and don't need online patronising about it. It is after all what I do for a living.
My question is not really about .nz since we have our signers, but about what kit will be available for registrars, hosting companies and enterprises as they come to rollout DNSSEC. They will have authoritative data, lots of it and will need the performance. They will also have a wide variety of internal security requirements so that some will need plain accelerators and some HSMs. For DNSSEC to be a success, registries need to be supporting their customers in many ways and not just thinking of their own requirements.
This is the second time you've come out with this attitude in this thread, and I for one don't appreciate it. This is a public discussion list, and while you are asking the question, many are reading the answer. I know and understand all of the above as well, but have found it valuable as it challenges some default assumptions people have about how to do this stuff. If this were some kind of business support line, I'd understand your response and lack of desire to be patronised, however that's not the case and on a public list you're going to get answers with more information than you need. If you want to consider that patronising that's fine - I'm sure the rest of us will be thankful to Joe for taking his time to present a whole lot of information and a different potential approach. (I know I do this as well sometimes as I'm sure many others do too, but, hopefully significantly less blatantly) Is anyone aware of DNSSEC software (OpenDNSSEC, what else is there?) being rolled in to Linux distros etc.? What about those control panel things that manage DNS for you (I think cPanel is one)? What is expected when DNS is hosted by a third party - someone like iServe that have a DNS management web interface etc.? Will they hold all the keys for the zone? Will the encryption for these keys require a password from the customer each time? Amazon EC2 does an interesting thing where you create a Windows VM and then ask it for the Admin password - you get shown encrypted data and a box in which to post your private key, and then there is what I believe is a Javascript routine that does the crypto operation to decrypt the password on the client side. Perhaps some kind of client-side signing operation similar to this makes sense? I doubt it'd be terribly practical, but maybe it's worth exploring. "DNSSEC Deployment Scenarios" sounds like an interesting NZNOG talk. (I'm hoping it hasn't already been done while I was having a uh meeting) -- Nathan Ward
Hi Nathan On 7/04/2011, at 9:56 AM, Nathan Ward wrote:
This is the second time you've come out with this attitude in this thread, and I for one don't appreciate it. This is a public discussion list, and while you are asking the question, many are reading the answer. I know and understand all of the above as well, but have found it valuable as it challenges some default assumptions people have about how to do this stuff. If this were some kind of business support line, I'd understand your response and lack of desire to be patronised, however that's not the case and on a public list you're going to get answers with more information than you need. If you want to consider that patronising that's fine - I'm sure the rest of us will be thankful to Joe for taking his time to present a whole lot of information and a different potential approach. (I know I do this as well sometimes as I'm sure many others do too, but, hopefully significantly less blatantly)
I'm sure we all see the value in comments that are general information that we all benefit from, but there is a big difference between that and telling someone how to do their job. The following para fell very clearly into that latter category:
With respect to performance, I think the realistic approach for provisioning purposes is to bear in mind that (a) even TLDs with extensive registrar/registrant DNSSEC uptake like CZ still don't see very high proportions of secure vs. insecure delegations, (b) insecure delegations (NS RRSets and associated glue) aren't signed in the parent zone, so zone size matters less than the number of secure delegations, (c) NSEC3 with opt-out avoids the signature burden of NSEC records, again scaling linearly with DNSSEC uptake by registrants, and (d) you can manage the signature load by imposing jitter on individual signature inception and expiry times to avoid having to do wholesale re-signing of the whole zone except in times of unusual system failure, at which point most bets are off anyway.
While that para is certainly of interest to many people, it is specifically telling a TLD operator not to worry about performance of signers because of the specific characteristics of a TLD zone and how they might reduce the performance burden. Asking whether those points had been considered would be reasonable and polite, but a lecture is patronising.
Is anyone aware of DNSSEC software (OpenDNSSEC, what else is there?) being rolled in to Linux distros etc.? What about those control panel things that manage DNS for you (I think cPanel is one)?
What is expected when DNS is hosted by a third party - someone like iServe that have a DNS management web interface etc.? Will they hold all the keys for the zone? Will the encryption for these keys require a password from the customer each time? Amazon EC2 does an interesting thing where you create a Windows VM and then ask it for the Admin password - you get shown encrypted data and a box in which to post your private key, and then there is what I believe is a Javascript routine that does the crypto operation to decrypt the password on the client side. Perhaps some kind of client-side signing operation similar to this makes sense? I doubt it'd be terribly practical, but maybe it's worth exploring.
The main products that support DNSSEC come into two types: - open source apps that you can integrate into your own signing process - BIND, OpenDNSSEC are two. - commercial appliances that are either "bump in the wire" boxes or full service platforms - Secure64 and Infoblox are two. I'll try to dig out some links to resource sites where this sort of information is being aggregated. cheers Jay
"DNSSEC Deployment Scenarios" sounds like an interesting NZNOG talk. (I'm hoping it hasn't already been done while I was having a uh meeting)
-- Nathan Ward
-- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
Folks, This is NZNOG, not another New Zealand mailing list that can be acrimonious at times. I quite like this mailing list. It doesn't need anything but tech. And if someone crosses the line, just hate them quietly, or snub them at the next conference. -JB
You're quite right. My apologies for biting on-list. Jay On 7/04/2011, at 10:34 AM, Jonathan Brewer wrote:
Folks,
This is NZNOG, not another New Zealand mailing list that can be acrimonious at times. I quite like this mailing list. It doesn't need anything but tech. And if someone crosses the line, just hate them quietly, or snub them at the next conference.
-JB
-- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
That's just to fiddle with the big numbers. Don't forget that you have to ask for trivial things like somewhere secure to store the numbers and the ability to tell if someone has tried to get the numbers without asking properly. Would we really trust an HSM with ccTLD key material if it hadn't undergone some industry accepted certification process? Unfortunately to get that level of compliance, things seem to head up the cost curve pretty quickly. Dean On 6/04/11 12:41 PM, Timothy Goddard wrote:
HSMs are expensive for a reason. $5k a unit entirely reasonable for that sort of specialised hardware. If much more than that, you should start asking questions.
On 6/04/2011, at 1:42 PM, Dean Pemberton wrote:
That's just to fiddle with the big numbers. Don't forget that you have to ask for trivial things like somewhere secure to store the numbers and the ability to tell if someone has tried to get the numbers without asking properly.
Would we really trust an HSM with ccTLD key material if it hadn't undergone some industry accepted certification process? Unfortunately to get that level of compliance, things seem to head up the cost curve pretty quickly.
Actually that last bit, FIPS 140 testing, is much cheaper than you think. The HSM market is just around the corner from being revolutionised at the low end with cheap USB devices like the Yubico that can do 10-100 sigs per second and are level 2 or level 3 compliant. BTW I'm well aware what kind of trust is needed in a ccTLD HSM ;-) Jay
Dean
On 6/04/11 12:41 PM, Timothy Goddard wrote:
HSMs are expensive for a reason. $5k a unit entirely reasonable for that sort of specialised hardware. If much more than that, you should start asking questions.
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
This sounds like a job for cheap graphics cards.
I've played around with network classification filtering, and it
wouldn't be hard to get it working with ccTLDs.
Have a look at :
http://upcommons.upc.edu/pfc/handle/2099.1/8800
On 6 April 2011 13:49, Jay Daley
On 6/04/2011, at 1:42 PM, Dean Pemberton wrote:
That's just to fiddle with the big numbers. Don't forget that you have to ask for trivial things like somewhere secure to store the numbers and the ability to tell if someone has tried to get the numbers without asking properly.
Would we really trust an HSM with ccTLD key material if it hadn't undergone some industry accepted certification process? Unfortunately to get that level of compliance, things seem to head up the cost curve pretty quickly.
Actually that last bit, FIPS 140 testing, is much cheaper than you think. The HSM market is just around the corner from being revolutionised at the low end with cheap USB devices like the Yubico that can do 10-100 sigs per second and are level 2 or level 3 compliant.
BTW I'm well aware what kind of trust is needed in a ccTLD HSM ;-)
Jay
Dean
On 6/04/11 12:41 PM, Timothy Goddard wrote:
HSMs are expensive for a reason. $5k a unit entirely reasonable for that sort of specialised hardware. If much more than that, you should start asking questions.
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
participants (9)
-
Dean Pemberton -
Gerard Creamer -
Jay Daley -
Joe Abley -
Joel Wiramu Pauling -
Jonathan Brewer -
Nathan Ward -
Richard Nelson -
Timothy Goddard