I am almost ready to submit a Windows 8 Store app to the store. As part of this process you must answer the question:
Does your app call, support, contain, or use cryptography or encryption?
It goes on to mention these possibilities:
Any use of a digital signature, such as authentication or integrity checking
Encryption of any data or files that your app uses or accesses
Key management, certificate management, or anything that interacts with a public key infrastructure
Using a secure communication channel such as NTLM, Kerberos, Secure Sockets Layer (SSL), or Transport Layer Security (TLS)
Encrypting passwords or other forms of information security
Copy protection or digital rights management (DRM)
Antivirus protection
(emphasis mine.) There are some exemptions:
Password encryption
Copy protection
Authentication
Digital rights management
Using digital signatures
My app was originally a Windows Phone app with limited ability to store or export data locally, so we have functionality to backup to or restore from SkyDrive. (For the purposes of this question the fact that SkyDrive may soon change its name is not relevant.) We put this same capability into the Windows Store app. The connection to SkyDrive is https - in other words we are using SSL.
Does this mean I need an Export Commodity Classification Number (ECCN)? Really?
From this page, Understanding export restrictions on cryptography, it looks like the answer is yes, SSL counts unless you are not transporting content over the wire. But I'm not a lawyer.
Does your app call, support, contain, or use cryptography or encryption?
This question helps you determine if your app uses a type of cryptography that is governed by the Export Administration Regulations. The question includes the examples shown in the list here; but remember that this list doesn't include every possible application of cryptography.
Important When you answer this question, consider not only the code you wrote for your app, but also all the software libraries, utilities and operating system components that your app includes or links to.
Any use of a digital signature, such as authentication or integrity checking
Encryption of any data or files that your app uses or accesses
Key management, certificate management, or anything that interacts with a public key infrastructure
Using a secure communication channel such as NTLM, Kerberos, Secure Sockets Layer (SSL), or Transport Layer Security (TLS)
Encrypting passwords or other forms of information security
Copy protection or digital rights management (DRM)
Antivirus protection
For the complete and current list of cryptographic applications, see EAR Controls for Items That Use Encryption.
Is the cryptography or encryption limited to one or more of the tasks listed here?
If you answered yes to the first question, then the second question lists some of the applications of cryptography that are not restricted. Here are the unrestricted tasks:
Password encryption
Copy protection
Authentication
Digital rights management
Using digital signatures
If your app calls, supports, contains, or uses cryptography or encryption for any task that is not in this list then your answer to this question is No.
Related
I am building up a small iot-like system, where mqtt devices(clients) are sending and receiving security-related critical information or commands.
I have got to know that TLS connection can be built optionally without client authentication thru PK certificate on the client side.
Normally, mqtt client devices don't have enough resources to support PKI, where at first it has to store a certificate and from time to time, to update it with newly issued ones when validity has passed or when the original certificate has been revoked.
That was, I think, why many of mqtt brokers have an option to configure on/off the client authentication during TLS handshake.
However, my concern is if there would be any security issue from passing the client authentication step, like, for example, a chance that some other malicious devices impersonating one of my devices can connect to the broker could obtain those critical information and commands.
My question is what best options and practices I can take to minimize that kind of risk considering the constraint resource of devices.
Missing client authentication means that everybody including an attacker can claim to be a valid client. There can be use cases like public services where this is not a problem and there are other use cases where the server wants to restrict access to specific known clients only.
There is no definitive answer to this question, it will always depend on the following factors, and only you as the designer can answer them:
What is the threat model you are working with? E.g. Who are you trying to keep out of the system and why, what are the consequences of somebody connecting a rouge client?
How much are you prepared to spend? If you intend to deploy client certificate or even a unique username/password for each device, how will it be protected? Does the hardware you intend to use support a secure enclave/hardware secret store? Meaning how hard would it be for an attacker to extract the client username/password or secret key from the device?
What other security measures do you have in place? Do you have Access Control Lists to protect which topics a client can publish/subscribe to? Do you have monitoring in place to detect malicious actions from clients so they can be disconnected and banned?
Suppose I have a mobile app which makes API calls to a server using HTTPS.
Would a malicious user be able to install Wireshark + Android emulator to inspect the API calls and by doing so get access to sensitive data like an API key?
I guess my question is whether Wireshark (or some other tool) can inspect the request before it gets encrypted.
If you control the client, then of course yes. Anything the client knows, its user may also know.
Without controlling the client, no, an external attacker cannot inspect or change https traffic unless they know the session keys. For that, they would typically use a fake certificate and make the client accept it (it won't do it by itself, and we are back at controlling the client).
Would a malicious user be able to install Wireshark + Android emulator to inspect the API calls and by doing so get access to sensitive data like an API key?
I guess my question is whether Wireshark (or some other tool) can inspect the request before it gets encrypted.
Yes this possible if the user controls the device he wants to intercept the API calls.
In the blog post Steal that API Key with a Man in the Middle Attack I show how a proxy tool(MitmProxy) can be used to intercept and introspect the https calls:
While we can use advanced techniques, like JNI/NDK, to hide the API key in the mobile app code, it will not impede someone from performing a MitM attack in order to steal the API key. In fact a MitM attack is easy to the point that it can even be achieved by non developers.
In order to protect https calls from being intercepted, introspected and modified the solution is to use certificate pinning:
Pinning is the process of associating a host with their expected X509 certificate or public key. Once a certificate or public key is known or seen for a host, the certificate or public key is associated or 'pinned' to the host. If more than one certificate or public key is acceptable, then the program holds a pinset (taking from Jon Larimer and Kenny Root Google I/O talk). In this case, the advertised identity must match one of the elements in the pinset.
and you can learn how to implement it in the article Securing HTTPS with Certificate Pinning on Android:
In this article you have learned that certificate pinning is the act of associating a domain name with their expected X.509 certificate, and that this is necessary to protect trust based assumptions in the certificate chain. Mistakenly issued or compromised certificates are a threat, and it is also necessary to protect the mobile app against their use in hostile environments like public wifis, or against DNS Hijacking attacks.
You also learned that certificate pinning should be used anytime you deal with Personal Identifiable Information or any other sensitive data, otherwise the communication channel between the mobile app and the API server can be inspected, modified or redirected by an attacker.
Finally you learned how to prevent MitM attacks with the implementation of certificate pinning in an Android app that makes use of a network security config file for modern Android devices, and later by using TrustKit package which supports certificate pinning for both modern and old devices.
While certificate pinning raises the bar, its still possible to intercept, introspect and modify https traffic, because it can be bypassed, as I demonstrate in the article Bypassing Certificate Pinning:
In this article you will learn how to repackage a mobile app in order to make it trust custom ssl certificates. This will allow us to bypass certificate pinning.
Conclusion
While certificate pinning can be bypassed I still strongly recommend its use, because it will protect the https communication channel betwwen your mobile app and API server in all other scenarios where is not the user trying to perform the Man in the Middle attack:
In cryptography and computer security, a man-in-the-middle attack (MITM) is an attack where the attacker secretly relays and possibly alters the communications between two parties who believe they are directly communicating with each other. One example of a MITM attack is active eavesdropping, in which the attacker makes independent connections with the victims and relays messages between them to make them believe they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker. The attacker must be able to intercept all relevant messages passing between the two victims and inject new ones. This is straightforward in many circumstances; for example, an attacker within reception range of an unencrypted wireless access point (Wi-Fi[1][2]) could insert themselves as a man-in-the-middle.[3]
Going the extra mile?
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
HTTPS request is encrypted on your host (client) before sending over the network, so it is not available for Wireshark. Wireshark can get hostname of the HTTPS web serserver you connect but not the URL.
I'm looking at how to set up a secure connection between a WCF service, and a non-.NET client running on RHEL, so I expect Windows authentication is not feasible. This is just for an internal network, so I'm hoping to avoid the management headaches of X.509 (e.g. needing to closely monitor certificate expiry dates), but I'm not clear on whether it's technically possible to do so.
Is it possible to configure a WCF service with e.g. BasicHttpBinding or WsHttpBinding so that it has encryption (either transport or message layer, I'm not picky), but without using Windows authentication support or X.509 certificates?
Every scenario I've read for secured WCF services seems to use one of those two technologies. The only ones which don't require any X.509 certificates all use Windows authentication. I'm not sure if this is a fundamental consequence of the underlying technologies or if it's just a property of the "common scenarios" that Microsoft has chosen to document. At the moment I'm assuming that if Windows authentication isn't available, then X.509 is the only way to deploy public/private key pairs for the non-Windows-specific message encryption algorithms to use. Is this understanding correct?
well ... it's just that "common" property ...
x.509 is the common way to do this in your scenario, since the most things needed for this are already there ...
but you are not limited to either windows auth or x.509 ...
take a look here: http://www.codeproject.com/Articles/165844/WCF-Client-Server-Application-with-Custom-Authenti
the article describes how you can introduce your own authentication and encryption schema ...
i've already done that (simple AES encryption, one key among all clients), but i don't have the code at hand ... it wasn't that hard, but if you really run into trouble here, i'll have a look if i still have that stuff somewhere...
I have multiple tiny Linux embedded servers on Beaglebone Black (could by a RaspberryPi, it makes no difference) that need to exchange information with a main server (hosted on the web).
Ideally, each system talks to each other by simple RESTful commands - for instance, the main server sends out new configurations to the embedded servers - and the servers send back data.
Commands could be also issued by a human user from the main server or directly to the embedded servers.
What would it be the most "standard" way of authentication of each server against each other? I'm thinking OAuth, assuming that each machine has its own OAuth user - but I'm not sure if that is the correct pattern to follow.
What would it be the most "standard" way of authentication of each server against each other? I'm thinking OAuth, assuming that each machine has its own OAuth user - but I'm not sure if that is the correct pattern to follow.
Authenticating machines is no different than authenticating users. They are both security principals. In fact, Microsoft made machines a first-class citizen in Windows 2000. They can be a principal on securable objects like files and folders, just like regular users can.
(There is some hand waving since servers usually suffer from the Unattended Key Storage problem described by Gutmann in his Engineering Security book).
I would use a private PKI (i.e., be my own Certification Authority) and utilize mutual authentication based on public/private key pairs like SSL/TLS. This has the added benefit of re-using a lot of infrastructure, so the HTTP/HTTPS/REST "just works" as it always has.
If you use a Private PKI, issue certificates for the machines that include the following key usage:
Digital Signature (Key Usage)
Key Encipherment (Key Usage)
Key Agreement (Key Usage)
Web Client Authentication (Extended Key Usage)
Web Server Authentication (Extended Key Usage)
Or, run a private PKI and only allow communications between servers using a VPN based on your PKI. You can still tunnel your RESTful requests, and no others will be able to establish a VPN to one of your servers. You get the IP filters for free.
Or use a Kerberos style protocol with a key distribution center. You'll need the entire Kerberos infrastructure, including a KDC. Set up secure channels based on the secrets proctored by the KDC.
Or, use a SSH-like system, public/private key pairs and sneaker-net to copy the peer's public keys to one another. Only allow connections from machines whose public keys you have.
I probably would not use an OAuth-like system. In the OAuth-like system, you're going to be both the Provider and Relying Party. In this case, you might as well be a CA and reuse everything from SSL/TLS.
I think you need to Implement Mutual Authentication between servers using SSL for your requirement.
I do not know much about M2M environment , but using OAuth for Authenticating your Servers is OverKill .
https://security.stackexchange.com/questions/34897/configure-ssl-mutual-two-way-authentication
Also Encrypting your Communication Channel while Sending commands would make it more safe from Attacks
I am developing and application in vb.net winxp+ (windows xp upwards). The application has to receive backup data from clients software located at different pc over the Internet. but am concerned about security of this application on the Internet.
what would be the best way to implement security in vb.net 2008 to make sure that the data is not sniffed or interfere with?
am thinking of encrypting the data before sending, saving it that way until it need to be viewed before decrypting.
what type of encryption would you suggest?
Is there any other way you would suggest this data be sent?
First of all your Server Application has to be a Windows Service. I imagine that your server will be always up, so a Windows Service is the right thing to implement.
Here you can find a reference on how to implement a Windows Service using .NET languages (it's very easy).
Then to secure the channel you have to do a choice about the type of encryption you want to use:
Symmetric: AES, 3DES, BLOWFISH, etc.
etc.
Asymmetric: SSL or your home
made protocol
The symmetric option (here is an example) has an hard key management because you have to store all the client's keys onto the server. Or you can use the same key, but it's not secure because you have to protect very well the client key. If an attacker gets the client's key, whole security infrastructure is in the hands of the enemy.
But you can have a different symmetric key for every client and the server chooses the right one. Anyway you have to protect the client's code and key (obfuscation and so on)
The asymmetric option (here is an example) is the best choice for me because you can have:
client authentication to the server
(the server has all the client's
public key and verify the sign)
server authentication to the client
(the client have the server's public
key)
channel encryption (channel is
encrypted with the symmetric session
key handshaked by the clients and
server through the public and private key)
The best and well-known protocol implementing the last one is SSL. You have to find APIs that implement it or you have to do by yourself (it's very hard to implement without bugs and security concerns).
Remember that you need certificate for SSL communications. X509 made via OpenSSL are good for your requirements and are easy to create.
There are two different things you should consider here.
Is it a requirement that the backup data are encrypted on the server, in which case clients should encrypt data using a symmetric cipher (e.g. AES) before doing the transfer.
For the transfer itself, SSL (https) would be a solid solution, with server-only authentication.