The problem:
I want to put a piece of software on a USB stick. The software needs to be effectively unusable without the USB stick in the drive, save perhaps for hardware tampering.
The software will not be mass produced; it has niche appeal, and we are therefore talking about maybe 1000-10000 units sold over its lifetime.
The USB stick can be non-standard in some manner, as a standard USB stick is normally user readable. The software will be running from the USB stick without any installation required, and ideally, it must function on computers without an active internet connection.
Is this possible ? Is there any way to achieve this, even to a limited extent ?
Thank you.
Hardware solution: Put an USB hub, a commercial USB software protection device and your USB data stick into a neat little plastic case.
Note: Some commercial software protection sticks may have enough internal memory for your application included. Cannot recommend products here due to site rules.
You could add a preregistered key to this USB and make it read only.
You can make it a read-only USB stick via software, via hardware or both (google have tons of ways of doing it)
This key could be as complicated as you please, a simple static word saved on a file, or a mathematical function that generates a key based on a common variable (software on the USB stick that runs when requested or when plug in, that generates a key based on the computer uptime for instance, something that can be verified by your software).
Your software only runs when this key is validated. On the software side you can also make it simple (search for a file in all available USBs and read static keys from a file). And you can make it more secure and complex, such as protecting the key with a asynchronous data encryption. And making the software only accept a specific versions or meta data coming from the USB device connected to the computer before reading the key from it, such as a specific serial number, driver and model name, (to make sure is one of yours).
All those things though can be hacked if a person wants to. Offline security validations are hardly failproof, but definitely you can keep most average ppl out of the loop.
You only need to evaluate how difficult you think is worth making it to crack. depends on your public and how bad it is to you if it is cracked (think about how many hours and effort a guy need to employ to be able to crack it, and if you believe that is more than what your target is willing to spend than you are probably safe)
Related
I've my C# NET6 desktop application to send to customers, important functions have been removed and implemented on a server
I've my public server on which I want to auth desktop app(license, feature...), get its blob, process it, send back
I consider the C# app crackable whatever obfuscator/protector I'll use (but i'll use anyway), server is considered secure, i need a secure point at customer premise.
The idea is to use an usb dongle to bring up a secure and authenticated session between desktop app and server.
Requisites for the dongle are:
Be able to do AES128(at least) and/or RSA1024(at least)
EAL5+/6+ secure MCU (nothing that could be dumped with glitches or baths in acid)
dll and API to talk with
So far i've looked at various sw protection dongle, but:
some are 15years old mcu and not sure if still in business
most doesn't tell what mcu is inside, some are fast (but silly) stm32, some are slow 8051
the expensive ones are the most complex ones, i mean it takes days to read unclear documentation and see that i don't need 90% of the package (enveloper, mssql db for my 50customers...)
i don't need at all their C# enveloper, I want to use a thirdparty/specific protector with VM
So i've looked at usb tokens PKI, FIDO2, PIV....but:
FIDO2 allows customer to reset pin and cear all certificates, no good as i want to burn keypair inside prior to ship to customer
PIV not found any cheap PIV only usb token, some FIDO2 expensive has also PIV interface, but...
to talk to FIDO2 and PIV i would need all the overload bloat of libraries that i very dislike (and also needs admin right, which i want to avoid)
PC/SC usb token are the most lowlevel to use, mscard lib and do whatever, nice but.....ISO-7816-8,9 are not public, costs like 300bucks to eventually see that my card vendor implemented custom stuff
I've 0x80 blob to send to dongle to powmod() it, that's all, no x509, no pkcs11, no base64, nothing human, just need a powmod(data) or an aes_dec(data).
Any suggestions?
While this is no full answer, I would like to address some issues:
You may underestimate the complexity required. Obviously necessary is some specification, whether RSA or AES operation is required. This has to show up somewhere, either as command parameter or as a set-up command (between host and connected token).
Pure modular exponentiation is unlikely to reach the desirable level of security, since RSA depends on padding to exclude some kinds of attack.
You may not like PKCS 11 interface, but it is proven and known to introduce no security issues. This may require notable effort if done on your own.
Given the mentioned EAL levels, my guess would be, that you need a smart card chip with USB interface.
The MCU is pretty irrelevant: to get crypto operations hardened, you need special hardware (as cryptographic coprocessors). It has little influence, how old the architecture of the chip is, which feeds the bytes to those.
I am trying to develop a custom cryptographically secure protocol for authenticating through an RFID smart card, all I can find over the internet are generic info on how write static Tags into the card.
For my project I need for the reader to send a Challenge nonce to the card (fixed length random bytes), then the card should send back the challenge encrypted with the hard-coded key (for example with AES CBC) or an hash HMAC.
The problem is: how can I program the card to do such behavior? I can write the code to do so, but how to "flash" it to the card. Also the code for the reader is not a problem (I want to use an Arduino with a reader module).
And then has a passive chip enough power to do this kind of calculations or is better to use an active one, considering that the distance would be few centimeters, such as behind a door?
A passive tag can't do this. Those just hold serial numbers that they spit out back.
You need some smarter card. You have basically two choices:
1) Choose a general-purpose card that fit your needs
The authentication scheme you describe is very widely used, and implemented by virtually all general-purpose smart cards, whether with contact or contactless (RF) interfaces (or both). If you go this way, you don't need to program the card with your own code, you just need to get the specs and initialize the card with the key value you want by sending the appropriate commands. And actually, with these cards, there are often generic tools available to initialize them. Easy.
Mifare (by NXP), for example is very widely used, easily available, and cards are cheap (drawback: it is certainly not the most secure cards ever made). You could use Mifare Classic - with proprietary NXP security protocol - specs here (be careful, the reader must be compatible) or Mifare UltraLight C, with open 3DES crypto - specs here. There are other variants, as well (e.g. Mifare Plus, which uses AES). Just don't go for the simple Mifare Ultralight, which doesn't provide authentication means. You'll see that for all these type of cards, there is a builtin authentication scheme that can functionally fulfill your needs (it is actually a mutual authentication, so it does more that what you require, but it's fine).
FeliCa (made by Sony), ACOS3 (made by ACS - specs here) are other possibilities, although I'm less familiar with it.
2) Get programmable cards
There are some, but it is not very easy to find for contactless and they are very expensive. You can lookup:
BasicCard (ZeitControl), which exist with dual interface. Those cards are programmable in Basic, and there are some kits available (but I'm not familiar with it either).
JavaCard (any manufacturer), which is a standard, but those are hard to find for small volumes. A few online shops seem to have some, though. These cards are programmable in Java (actually a subset of Java). There are tools available for the development phase (from Oracle, or even as Eclipse Plugins, for example). Then, for loading your custom applet in the smart card, you need to get familiar with GlobalPlatform, which is another (publicy available) standard, describing the way applications are managed in a smart card. This would be too broad to describe in detail here, though. You can find resources on the internet, but this road is definitely the most difficult.
Note, that NFC just describes the communication method and tells nothing about the intelligence available on other side.
More intelligence is needed (the command you seem to look for is called EXTERNAL AUTHENTICATE in ISO 7816-4), but does not help for your range problem, since the weaker the field, the less power is available. The idea of having communication through the door will only work for doors which are so weak, that a high-tech electronic protection won't improve overall security. The maximum distance achievable with standard field strength (heart pacemakers and similar devices limit that one) with nothing more than air between suffices typically for something like 10 centimeters. So for me it seems that your reader has to be on the outside and needs to be mechanically hardened against tampering itself.
(What would help, is a "card" with its own power source, so the field is only required for communication. As far as I know, this is mostly provided by a sort of external sleeve.)
What dim fails to mention is the product group of so-called native cards, which are typically only programmable with significant manufacturer support (non-disclosure agreement, probably fee involved), but luckily contain functionality for most use cases already, in your case the commands Get Challenge and External Authenticate.
I am very interested in device driver programming .I have started reading the LDD3 ,there author said
"to become a device driver programmer you have to understand your specific device well"
can any one tell me what is the meaning of the "understand your specific device" .what are the thing I should know before writing a device driver.
Thanks
That's a basic list with software and hardware combined.
The Operating System driver API
The processor architecture as it relates to hardware interfacing
The 'bus' structure that interfaces the device hardware to the processor
Interrupt Handling
Dma Control
Processor Caching
Processor MMU control
OS Semaphores and scheduling
Data/Byte Alignment
Assembly language when needed
Control of Instruction Execution Order and Optimization
Consideration of performance issues
What's IO and memory mapped hardware ?
http://www.cs.nmsu.edu/~pfeiffer/classes/473/notes/io.html
This link talks about generic hardware access in Linux device drivers.
http://www.linuxforu.com/2011/06/generic-hardware-access-in-linux/
This is specifically about USB hardware
http://www.beyondlogic.org/usbnutshell/usb2.shtml
Check lwn.net it never disappoints a device driver developer.
https://lwn.net/Archives/
Last, but not least, They have everythig, CPU, Memory, Camera, PCI..
http://www.hardwaresecrets.com/page/memory
-
Hi, I'm very pleased to share what I have learnt with you guys.
Yes, it is the basic need to know your device if you wanna be a device driver programmer. I also want to be a linux device driver programmer, or even more, though I have some device driver experience under other software platforms.
The reason why you wanna contact with it is that you wanna make it do something for you.
Normally, what it can do is the first thing you must know. It's very obvious that you will never send Ethernet frames through UART or SPI, right?
There exist various kinds of devices in the world, such as, storage device, FLASH, SD card, harddisk; communicating devices, network card, wifi; interconnected bus, PCI-express; how many there are.
After that, the next thing you will concern is how you can do to reach your goal.
To access the device, reading, or writing, there is usually a controller embedded in the processor. Here, when I say "processor", it means it is a core integrated with various kinds of controllers, no matter pc desktop or embeded system areas.
The Controller is the interface you will face, to work on the device behind the controller.
Through the controller, you can ask the device to do what you want. In the controller, there are registers, which are the deepest points the software can touch. Beyond that lies the hardware, as you are a device driver programmer, it is very common for you to communicate with hardware engineers to make things done.
If going into details about the register, there are control registers used to tell device what you want it to do, status registers, used to reflect the status of operations underway in devices, if interrupt is supported by that device, there are also some registers for you to deal with interrupts.
Well, I almost forget there are also data registers, whicha are used to store the data to be sent or written, or to be read by user. According to the specific implementation, registers used to store data from upper users to be sent or written and registes used to hold data from outside that will be read by users may be the same, or may be not.
In a normal way, if you wanna let someone do something for you, you should provide something to him first. Whoever wants to do anything, there must be some inputs to him, right?
in a summary,
action(read,write,or others) + data(you give, or you ask for) + status(what progress it is)
what it can do
how it does that, how to assemble the command cell, time sequence?
what you must provide it to reach your goal
genarally, two kinds of things you should provide:
if you ask for, where to store what you ask for;
if you give, where are what you give
how it reflects the progress of operations， polling or interrupts
Well, that is all I want to share with you.
Thanks.
Is it possible to make a computer behave as a bluetooth HID device? That is, given a local machine with a standard USB keyboard plugged into it, other devices could discover this machine and use it as a bluetooth keyboard.
I'd like to create a linux or OS X application (or use an existing one, though I've found none) which can behave as described above, but I'm not sure where to start, or if it's even possible.
So:
Is what I'm describing possible?
Are there any existing applications that do what I describe?
If no application already exists (I'm assuming not), are there bluetooth libraries or bindings that will help? (I'm pretty comfortable using most of today's popular languages, so I'd prefer a library most directly suited to the task, so long as it's available in linux or OS X.)
Failing any of the above, the bluetooth spec looks pretty dense. Are there specific guides or other starting points applicable to the problem at hand that I can read?
I realize that such an application would most likely need to steal the normal keyboard input, possibly providing some KVM-like hotkey for switching between providing input to the host operating system and sending the input over bluetooth to the connected device, but I'm considering that problem to be outside the scope of this question.
It is definitely possible on Linux. Some time ago I found this project:
http://nohands.sourceforge.net/index.html
They emulate a full-blown headset with audio and keyboard controls on the Linux bluetooth stack. If they can emulate something like that, you would probably be able to emulate something simpler like a keyboard.
It is possible, however I don't think I'll be able explain it very well and I don't know the entire answer. A BT HID device works as a server and waits for connections to come to it. In linux, using the bluez stack, first you would have to advertise the HID service for other devices to see. I think you do that using the sdp.h and sdp-lib.h header files(the second header maybe called something else, I'm on a windows computer and can't check). So you would have to add the HID service record to you computer for other devices to see it. You would have to create a program that first adds this service to the record, then waits for other devices to connect, then handle the pairing process, Bluez might handle this for you, or you might have to do some things to it, I'm not quite sure. You should also read the Bluetooth HID Spec found at the http://www.bluetooth.com/English/Technology/Building/Pages/Specification.aspx site. This document contains the details of the SDP record relevant to HID. Also the book Bluetooth essentials for programmers is pretty good to introduce you into bluetooth programming
I would like to have given a more concise answer, with more detail, but that's all I know ATM. I am also trying do something similar, but spare time is so hard to find ;) I'm also not on my Linux box and can't check all the details. If your are still interested, let me know and i'll try to expand my answer.
I don't know if this is helpful, nor if it is still alive and working, but perhaps you could try this link.
Another one that might or might not be helpful in some way is remuco, but I don't know if they are using a Bluetooth HID profile.
It is indeed entirely possible with Linux and Bluez. See: https://github.com/lkundrak/virtkbd/blob/master/btkbdd.pod
Try Across, unfortuantly for me my phone was lacking support.
Suppose you want to add an extra layer of credentials on top of a SSL-encrypted login/password, but you don't want to increase complexity to the user. Is there a way to add the requirement of the possession of a dongle to web-server authentication schemes with existing cross-platform browser capabilities?
In other words, to get access to the web-site, you would need a username, password, and a USB dongle that has been plugged into the client computer. The dongle would presumably do some sort of challenge/response.
It'd be ideal if this dongle solution worked with Firefox automatically or with the simple addition of a plugin.
Thoughts and suggestions are appreciated.
You may be interested in the Yubikey.
It's a small usb dongle that acts as a usb keyboard (i.e. needs no special drivers or client software) and is designed exactly for this sort of authentication.
You could use RSA SecurID tokens, which are little keychain displays that change the number displayed every one minute. In addition to requiring the username and password, you can also require them to enter the number they see on their token to verify they have the hardware device with them. There are various hardware dongles, with some even requiring a PIN to be entered to see the changing number. The is extra complexity on the server side, but the client doesn't have too much trouble.
I've also used the Yubikey with good results. Another similar solution is the Swekey - you might want to check that out also.
I've had good results implementing website authentication and login using Dinkey Dongles and the DinkeyWeb system.
The user plugs the usb security dongle into their machine, visits your "protected" web page and it validates the dongle before loading the page. Works without special permissions or privileges.
Hope it helps.
It's going to require something that has the rights to access the dongle. There is also the issue of hacking it--the communications aren't going to be able to be hidden so you have to make sure it doesn't matter. That means the dongle is going to have to implement it's own crpyto. You'll also need support for whatever systems you are going to support.
I see this getting very complex very fast.