We're going to add Fingerprint authentication to an iPad app;
Since we couldn't find any actual fingerprint hardware that works with an iPad, we found DigitalPersona, which is a supplier of great fingerprint scanner hardware, as well as an SDK for Linux C/C++. The idea is that the user would tap "authenticate with fingerprint" which would send a RESTful request to the linux box with the fingerprint scanner; the linux box would be running the compiled C++ program which waits for a user to scan their finger, determines a match or no-match, and send that response back to the iPad program's original request.
So... with very little C++ experience, and even less CGI (but lots of PHP and Objective-C), I was wondering if this is technically possible. Can a CGI binary accessed via HTTP actually wait for local user input (at the console) before sending the result to the HTTP request?
The linux box would run headless, and we'd control some LED's to help with letting the user know that the program is waiting for a fingerprint scan.
SOME Additional Details:
No PHP is planned on being used. Initially, we want three devices:
iPad
Linux
Server
iPad is running an app which would have a biometric authentication IBOutlet;
Linux has the fingerprint scanner on it, and a basic Apache; additionally the C++ SDK for the finger print scanner, which we would use to build the CGI program that, when invoked (by server), waits for a finger scanned, and once scanned, sends a "match" or "no match" to it's requestor.
Server would be the requestor. Once it receives a request from the iPad app, it invokes the CGI program on the Linux box, waiting for a "match" or "no match" request.
Another member of my team offered this:
iPad is running the app; user clicks 'auth with fingerprint' and the iPad is in a 'waiting' state
Linux has the finger print scanner, user scans finger print, and the finger print gets sent via HTTPS to the server
Server would receive a finger print, and match it up with a user. then checks if any iPad is in a 'waiting' state, and which user initiated it. If it matches the finger print-authenticated user, it would accept the iPad's data as an authentic punch, and release the iPad from the waiting state.
http://sveinbjorn.org/files/ObjectiveCGI.zip
There are basically two ways of doing this; you could have your PHP function call an external application through exec or you could write an external CGI in C++ directly using RudeCGI, Cgicc or freeCGI. There are a lot of libraries for you to choose from.
Why CGI need to wait for user input? You can rather invoke the CGI after taking input from Iphone and send it to the CGI...You then just have to read CGI response from Iphone...
Related
I have an imaginary program that I've distributed to dozens of clients which involve their home thermostats. The script performs two tasks:
When a request from my server is received, the script will modify the temperature of the user's thermostat to the designated temperature.
When a request from my server is received, the script will reply back the current set temperature of the thermostat.
The program being ran on the clients computer is programmed in a scripting language and is not compiled. The source code can be modified at any time and the new modified script can be re-ran at will.
I have three problems:
What changes can I make to the script running on the client's computer and/or the program running on my server such that I feel more confident that the user did not tamper with the source code of the script?
How can I be relatively sure that the user is running the most up-to-date version of my program?
Without using IP addresses, how can the client know a request came from the server and not another client?
I understand that code running on a client's PC is impossible to police. However I want to make it less trivial for someone to modify the source code of my script.
As you correctly point out, it's impossible to guarantee nobody modifies your source - or replaces your client with an entirely different one they write from scratch. It simply cannot be done and it's not even because your client is implemented as a script; binaries can be replaced/spoofed as well.
What changes can I make to the script running on the client's computer and/or the program running on my server such that I feel more confident that the user did not tamper with the source code of the script?
Make your script compute a cryptographically secure hash of its own source code and send that hash to the server. You'll know what the hash of your client's source code is and can make sure this is the same. This does not guarantee the client is not pretending to be running your source (they could compute the hash of your client and send it while running entirely other code) but this will prevent casual and/or accidental modifications to the script from working (i.e. it guarantees any spoofing is intentional).
How can I be relatively sure that the user is running the most up-to-date version of my program?
Include a version number in the client source code you distribute so you can guarantee each new version has a unique hash with almost 100% probability. Then, you can have a history of versions with corresponding client hashes.
Without using IP addresses, how can the client know a request came from the server and not another client?
This one you can actually do correctly. Have your server use its private key to sign the messages it sends, and have your client verify the signature using your server's public key (which the client source code can contain). Since only your server could possibly have signed the messages with the correct private key, the client can be confident that success with the corresponding public key means your server sent the message.
If it is a home thermostat, the whole architecture is likely wrong. Your server will not be able to connect to devices on your customers' home networks (or at least they will have to perform configuration that you should not expect to be done).
So in a better architecture, you have your service on the internet, to which your devices connect. Note that these connections can be long ones as well, not necessarily just the typical short-lived http connections.
The client software running on a device can be modified by your users arbitrarily, or they can make other clients, you cannot do much about this. In reality, unless this is very valuable for some reason, nobody will bother, especially in a commercial way, because any change to your api will break 3rd party clients. One option to still make client code harder to modify is obfuscation, but be aware that it is not really a security feature, but it does increase the necessary effort.
Checking the version of the client is straightforward, it can just be sent with requests. However, the usual way to achieve what I think you wanted is to version your API. You probably don't care about the exact version of the client, but you do care about which version of the service (the API) it supports. If that is your goal, look into API versioning.
Authenticating the server in this architecture is straightforward if communication uses TLS. With TLS (eg. https), server authentication is implicit. You still want to authenticate the client though, which can be done via the standard means, a username-password, tokens or a client certificate. When talking about devices, you might want to consider a device with a TPM chip so that it can securely hold secrets, but whether you need that depends on the exact scenario and your threat model (who will have physical access, what happens if they can impersonate other devices and so on).
I have a web-server with an SSL certificate, and an unsecured device on a GSM/GPRS network (arduino MKR GSM 1400). The MKR GSM 1400 library does not feature a SSL server, only an SSL Client. I would prefer to use a library if that's possible, but I don't wanna write a SSL Server class. I am considering writing my own protocol, but I'm familiar with HTTPS and will make writing the interface on the webserver side easier.
The GSM Server only has an SSL Client
I am in control of both devices
Commands are delivered by a text string
Only the webserver has SSL
My C skills are decent at best
I need the SSL Server to be able to send commands to the Arduino Device, but I want these commands to be secured (The arduino device opens and closes valves in a building).
The other option would maybe have some sort of PSK, but I wouldn't know where to start on that. Is there an easy function to encrypt and decrypt a "command string". I also don't want "attackers" to be sending commands that I've sent before.
My Basic question is, does this method provide some reasonable level of security? Or is there some way to do this that I'm not thinking of.
While in a perfect world there would be a better approach, you are currently working within the limits of what your tiny system provides.
In this situation I find your approach reasonable: the server simply tells the client using an insecure transport that there is some message awaiting (i.e. sends some trigger message, actual payload does not matter) and the client then retrieves the message using a transport which both protects the message against sniffing and modification and also makes sure that the message actually came from the server (i.e. authentication).
Since the trigger message from the server contains no actual payload (arrival of the message itself is enough payload) an attacker could not modify or fake the message to create insecure behavior in the client. The worst what could happen is that some attacker will either block the client from getting the trigger messages or that the attacker fakes trigger messages even though there is no actual command waiting from the server.
If the last case is seen as a problem it could be dealt with a rate limit, i.e. if server did not return any command although the client received a trigger message than the client will wait some minimum time before contacting the server again, no matter if a trigger message was received or not. The first case of the attacker being able to block messages from the server is harder to deal with since in this case the attacker is likely able to block further communication between client and server too - but this is a problem for any kind of communication between client and server.
I'd like my Fenix 3 to do the following:
Trigger = hold down start button (i.e. shortcut)
Send message via BT or WiFi to a server (Linux or Windows or Arduino or whatever)
I'll take care of the message and open/close my garage door.
After a bike tour I'd like to easily and safely open my garage door. I have a VmWare server running at home. I could use one of the machines on this server to listen to the messages or I could set up an Arduino or similar.
The main question is: Can I write an IQ app that utilizes the shortcut concept on the clock, i.e. triggered by long click on start or lap button?
Clarification: There seems to be some kind of global actions for long press. I can for example assign "Save position" to long press on start/stop. This works even from inside of other apps.
Can the clock communicate with sensors (i.e. Arduino or other BT client) even if not in training mode?
Clarification: I need to communicate directly with my Arduino via Bluetooth, i.e. not via my iPhone.
Thanks in advance.
Short answer: Yes
Long answer: If you record the time a keydown event comes in, and then check for a "long" press when the key is let up based on the time difference, you can fake it. There is not an event for a long press of a physical key though. I am also pretty sure your app needs to be the current one for this to work.
Link to the InputDelegate event options: http://developer.garmin.com/downloads/connect-iq/monkey-c/doc/Toybox/WatchUi/InputDelegate.html
As for the sensors question, I am not sure exactly what you are asking. Your app can do whatever you want, and it is my understanding that only one app will be running at a time.
Disclaimer: Thus far I have only been working with the emulator, I'm still waiting for my watch to get here.
You cannot write anything that hijacks user input events from another active application (including the watch face). You could make your own watch face, but it wouldn't have the ability to send network messages and it has only one way to accept user input (the look-at-watch gesture).
This is something that you can do pretty easily from a watch-app or a widget. Assuming that your fenix3 is connected to your phone via bluetooth, you can send http get requests as you see fit.
I've written a simple app that I call GIFTTT that uses the IFTTT Maker channel to open/close my garage door (and all sorts of other things).
I'm developing a simple 2d online game and now I'm designing my server. The server will be run on linux vps and I need a way to communicate with it (for example to close it, and as it will be run on vps, simply closing terminal won't work). So I think there are 2 options:
1) Write 2 apllications - server which doesn't say anything and doesn't accept console input and the second application is console which sends commands to server (like exit, get online players etc).
2) Write 1 application which has 2 threads - one is the real server, the second thread will be used for cin and cout. However I'm not sure if this will work on vps...
Or maybe there is better aproach? What is the usual way of doing this?
Remember that it must be vps-compatible way (only ssh access to it).
Thanks
I would go for a "daemon" (server) for the main server function and then use a secondary application that can connect to the server and send it commands.
Or just use regular signals, like most other servers do - when you reconfigure your Apache server, for example, you send it a SIGHUP signal that restarts the server. That way, you don't need a second application at all - just "kill -SIGHUP your_server_pid".
I want to a Java ME application that transfers any SMS received to a PC using bluetooth. The PC can then direct the Java ME application via bluetooth to send a response SMS. Is there library available for this architecture or I have to design it myself?
Is this approach correct or a better one exists? I want to use bluetooth as then I will not have dependency on the cable.
You'll need to create this yourself, however you'll find that you can't do what you want with J2ME.
J2ME can't access any old SMS that the handset receives, only ones sent to a specific port upon which the MIDlet is listening. So to get all the other SMSes, create a bluetooth serial/dial-up connection to your handset in the way I've described in this answer.
Create a PC client which repeatedly issues AT+CGML commands (as described in the AT command set document linked to in the answer above), to see when an SMS has been received. Use AT+CGMR to read and parse the message text. Then use AT+CGMS to sent a response. This can all be done over bluetooth.
It's better to use the serial connection to send a response, because a MIDlet cannot usually be triggered to open based on incoming bluetooth data.
Hope this helps.
You may have already achieved your task, anyway for the reference I think it is much better if you try using Gammu . I'm using it for the same task (Send / receive SMS through PC ) with a simple bat file I have written, works like a charm.
Anyway you don't need any J2me program for this.
Wammu takes care of making the connection to phone and sending AT commands.