|
Home > |
|---|
This section provides additional information by answering questions that are frequently asked by our customers.
No. The SafeNet Network HSM 1700 appliance comes with a single power supply, and you can purchase a second PS, remove the blanking plate and install the new PS into the empty slot for the same power-supply redundancy as SafeNet Network HSM 7000, but you cannot increase the SafeNet Network HSM 1700 performance. If you need the performance, buy a SafeNet Network HSM 7000.
Note that you could buy and use the less-expensive SafeNet Network HSM 1700 for your testing, development, or integration, and then purchase SafeNet Network HSM 7000 appliances for your operational deployments where higher performance is desired. Other than performance, the two appliance models are functionally identical. An integration or application that works with one will work with the other, with no adjustment needed.
Note that the main difference (see next question) is performance using asymmetric operations. If your primary cryptographic activity is key-generation of any kind, or involves mostly symmetric operation, then SafeNet Network HSM 1700 should suit your needs at a smaller investment.
Here is a quick summary of some excerpts from the performance testing:
• Key Generations – same performance for both
•Symmetric operations – same performance for both
•Asymmetric operations – check with your SafeNet Sales representative, but here are some samples.
– RSA 1024: 7000 signings/second vs 1700 signings/second
–RSA 2048: 1200 vs 350
–RSA 4096: 160 vs 50
–ECC P-256: 1000 vs 490
We provide repeatable numbers that you could achieve if you tested in an environment similar to our test-lab environment. This method provides numbers that you can compare against numbers from any of our competitors. In general, that means automated scripting to perform a given operation with a "standard" keysize, or standard input parameters, and ensuring that no other operation or latency is allowed to intrude - an isolated high-speed network with no other activity.
Operation outside a controlled laboratory environment is messy and sometimes unpredictable, with many variables that could affect testing if we did not control the parameters and conditions as tightly as possible. Therefore, all manufacturers' test numbers tend to be the best you can get under ideal conditions.
So, for example, we use the RSA 1024-bit key as the standard for performance of asymmetric sign and verify operations, because that is what the industry uses as a common basis of comparison. That remains true even though the 1024 key size is now generally considered too small for modern operational use, and most applications would tend to use 2048 key sizes (at least that was the case when this was written in 2013).
As well, we bombard the HSM with at least 30 threads simultaneously performing that simple test operation (this is down from a previously required 50 threads due to refinements in SafeNet Network HSM 5.2). Any fewer might fail to exercise the HSM to its fullest. Significantly more threads would not increase the performance numbers, so we work in the "sweet spot" and we suggest that you do as well if performance is your greatest concern.
In operational, real-world situations, your clients are likely to have other responsibilities, or might make other requests of the HSM - for example, a fresh asymmetric key generation before each asymmetric signing operation would slow the sign/verify performance down to key-gen speeds... orders of magnitude slower than simple, repetitive signing that reuses a single key. Network latency and other factors also serve to degrade performance in non-laboratory operation.
Remember that our numbers are not based upon sequential access, but are based upon an optimal number of concurrent threads accessing the HSM. That optimal number differs from one HSM to the next. Best performance for the legacy SafeNet CA4 is achieved from roughly 4 - 8 threads with a slight drop-off after that due to the overhead of context switching. On SafeNet Network HSM 5.0 and 5.1, the optimal number of threads has been in the range of 50, but refinements in SafeNet Network HSM 5.2 have brought the optimal number of concurrent threads down to 30.
Command latency (the time required for any one command to complete) is not a direct inverse of TPS, and can be dependent on several things including the number of threads, the network latency, and the interleaving of different command types to the HSM. (That is, ideal signing performance can be achieved only if the HSM is processing only signing requests.) As the number of threads increases (and thus the corresponding TPS) the latency increases as well. So you might be seeing what appears to be 6 responses per millisecond, but the round-trip latency of any one of those commands might be as high as 500 ms (for example).
This is partially why, when you observe numbers from our tools, the numbers are quite variable for the first several seconds, and then settle around stable values as the testing proceeds.
Performance requirements should state both the total throughput and the maximum latency that a command must execute, and the ideal number of threads should be adjusted accordingly.
You are thinking of the HSM's flash memory, which would be used to store token objects. By their nature, those do not frequently change.
Your "key factory" application (generating keys that are pushed out to external devices like smart cards) should be generating your short-lived keys as session objects, rather than as token objects. Session objects do not use the flash memory at all - they are created and exist in the HSM's RAM only, which can perform virtually unlimited read/write operations.
SafeNet Network HSM 5.2, and later, can do about 35 ECC P224 keys per second. You would then need one appliance for performance reasons, if you could count on steady demand with no peaks. Consider having a backup as well.
In the situation where you might encounter bursts of key generation traffic, prudence suggests one operational SafeNet Network HSM, one in standby to accommodate the burst traffic, and a third unit for backup.