I'm using a Windows Mobile 6.5 device, and was wondering, is there a way to enable FIPS only mode on it, the way you can in Windows 7 and XP?
The equivalent setting I've found on a desktop OS is:
Security Settings/Local Policies/Security Options/
System cryptography: Use FIPS compliant algorithms for encryption, hashing and signing = Enabled
I'm looking for either an equivalent setting, or a registry fix (assuming it is even possible).
There is an explanation of what FIPS is at the Mozilla site. FIPS mode enforces stricter security practices throughout the OS. It is important because it is a requirement for those that need to be FIPS-compliant (which many branches of the government require).
If it helps, we are using the RSAENH cryptographic module in our application.
No, there's no such provision in Windows Mobile 6.5.
From http://technet.microsoft.com/en-us/library/cc750357.aspx, we can see that the Microsoft cryptographic libraries do not check the FIPS local policy flag at all and it's up to applications to do so.
Note – There is no enforcement of the FIPS policy by the operating
system or the validated cryptographic libraries (CAPI or CNG).
Instead, each individual application must check this flag and enforce
the Security Policy of the validated cryptographic libraries.
(If you're wondering, the .NET framework counts as an application here and it is what checks the flag on the Desktop OS—not the underlying crypto library)
Knowing this, you have to look at the Security Policy for the Windows Mobile Cryptographic Provider (RSAENH) to find out how to ensure FIPS compliance:
Secure Operation
The Microsoft Windows CE and Windows Mobile Enhanced
Cryptographic Module (RSAENH) is used in FIPS Approved Mode by
application, through the invocation of individual functions in FIPS
Approved Mode. The application is responsible for ensuring that it
does not perform non-Approved functions in ways that make the
application non-FIPS Compliant. The non-Approved functions include:
• Any function using an algorithm which is non-Approved
Further, the Security Policy mentions what are the non-approved FIPS algorithms. It's up to you to make sure you don't use them to remain FIPS compliant. These are the non-approved algorithms that it lists and you must not use:
RSA keypair generation (key sizes from 384 to 16384) (the RSAENH module does not implement the Approved X9.31 algorithm for keypair
generation)
RSA encrypt and decrypt with private and public key
RC2 keypair derivation (key sizes from 40 to 128)
RC2 keypair generation (key sizes from 40 to 128)
RC2 ECB / CBC encrypt/decrypt
RC4 keypair derivation (key sizes from 40 to 128)
RC4 keypair generation
RC4 encrypt/decrypt
MD2 hash
MD4 hash
MD5 hash
MD5 based Keyed-Hash Message Authentication Code (HMAC)
non-Approved Software Psuedo Random Number Generator (PRNG) (seeded by hardware data, and by application-provided data)
Lan Manager Hash Generation
Related
Golang provides https://pkg.go.dev/crypto/x509 library for processing certificate and also Rust provides similar library https://docs.rs/x509-certificate/latest/x509_certificate/.
According to https://docs.rs/x509-certificate/latest/x509_certificate/#security-disclaimer it seems not to be production ready.
How should I create a certificate programmatically in Rust, in a production-ready fashion?
There is also https://github.com/sfackler/rust-openssl but not sure should I use it or not.
I'm trying to learn a little about Windows application development, and I have yet to wrap my head around certificate handling.
Is encryption and decryption handled by Windows OS functions, or by fetching the private key from the store and performing the cryptographic tasks separately?
An example: assume I have some web page hosted with IIS using SSL certs.
Is e.g. the IIS web server using api calls like the one below, or does IIS ask the OS to encrypt/decrypt using some user selected cert from the store?
https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.x509certificates.rsacertificateextensions.getrsaprivatekey?view=net-5.0
I na given case, IIS acquires private key handle and calls CrypoAPI functions to performs cryptographic operations. Though, IIS doesn't use referenced API, it uses native functions directly.
Windows uses abstraction layer by defining APIs for cryptography and one important part of these APIs is key handle. OS may not have access to raw key material and use key handle to access the key by key owner. Key owners are implemented as Cryptographic Service Provider (CSP) or modern Key Storage Provider (KSP). When necessary, OS calls implemented API and pass key handle to CSP or KSP. Then CSP/KSP implementation is responsible for raw key material access actual cryptographic operations. CSP/KSP implementation is vendor-specific. Windows ships a dozen of software-based CSP/KSP implementations and 3rd party vendors may ship their own implementation, especially when key stored on a hardware (smart card or HSM).
In any way, OS don't care how and where the key is stored, it simply calls defined API, passes key handle and input parameters. CSP/KSP then accesses raw key material, perform requested operation and return result back to caller.
And here is the answer to your question: cryptography operations are handled by CSP/KSP that owns/stores particular key identified by key handle. Whether it is OS or not depends on CSP/KSP implementation. If it is software, then most likely (not necessary, but very often) it is handled by OS. If it is hardware, then it is handled by hardware itself.
I would like to disable ecdhe cipher in IIS / windows 2008
I know how to list out all cipher is running , but how to disable it ?
Can anyone guide me in this ?
The cipher suites are in your operating system, not in your web server. You can prioritize, add or delete cipher suites via regedit, but I highly recommend you to use IIS Crypto for this. It'll allow you to perform all the previous actions, and it also includes a default configuration to remove all the insecure ciphers, like RC4, or insecure hash functions, like MD5.
But I'm curious about one thing, Why do you want to disable ECDHE? I mean, Elliptic Curve crypto is really awesome, since it allows you to work with short keys, providing the same level of security that you could get with much larger keys when using a different key exchange mechanism. I can't think of any good reason to disable it.
The Linux kernel has a cryptographic API that uses cipher names described like aes-xts-plain64 and aes-cbc-essiv:sha256 (these examples are the default ciphers used by the Linux cryptsetup tool). The names comprise
a cipher : aes
a mode : xts
a method to generate an initialisation vector : plain64
These descriptions differ from OpenSSL which uses a different format. You can list the openSSL ones with openssl list-cipher-commands and the available ciphers loaded in the current kernel can be seen with cat /proc/crypto.
Given data encrypted by the kernel API, can it be decrypted using Ruby?
I can think of two approaches to this problem: use Ruby bindings to either the kernel's Crypto API or OpenSSL.
I have tried both approaches. I have not been able to find a way to use the kernel API from Ruby. I have used OpenSSL but it isn't clear how to translate the kernel's cipher string into one that OpenSSL understands.
Is it possible to store passwords on the local system (Windows XP) that can only be accessed by the application itself?
My instinctive answer would be "no". Even if some kind of hashing or encyption is used I would think that as long as the source code is available then the determined seeker could always use this to retrieve the password.
I'm working on a personal open source hobby project in which I would like to give users the option of storing passwords on disk so that they don't need to type them every time they use the software. One example of a password that could be stored would be the one used to authenticate on their network's proxy server.
There are a few related questions here on Stack Overflow and the most appropriate solution sounds like using an operating system service like DPAPI.
Is the basic premise correct that as long as the password is retrievable by the software without any user input, and the source code is open source, that the password will always be retrievable by a (suitably technically and willfully inclined) passer-by?
You could read about the Pidgin developers' take on it here:Plain Text Passwords.
Using the DPAPI in UserData mode will only allow your account on your machine to access the encrypted data.
It generates a master key based off of your login credentials and uses that for the encryption.
If the password is retrievable by the software without any user input, then the password will always be retrievable by a (suitably technically and willfully inclined) passer-by. Open or closed source only affects how much effort is involved.
Absolutely, you can write a program to store passwords securely.
Using AES, you could have your program generate an AES Key, and have that key stored in an operating system protected area. In WinXP, this is the registry, encrypted with DPAPI. Thus the only way to access the key is to have physical access to the machine.
You need to ensure that when you generate your AES key that you do so in a cryptographically secure manner. Just using RAND won't work, nor will generating a random character string.
Open Source has very little to do with security (in my opinion). Given the level of sophistication in tools for reverse engineering source code, even if you had a closed source solution, people determined to snoop at your code could do so.
Your effort is better spent ensuring that you follow best practice guidelines while using the chosen encryption scheme. I would argue that having your code openly looked at by a larger community would actually make your code more secure; vulnerabilities and threats would likely be identified sooner with a larger audience looking through your code.