I want to develop an App in Android 6. I need to transmit iBeacon packet.
As I checked in iBeacon advertisement packet spec we need to transmit UUID along with major number and minor number.
So my question is this
Is there any process/License for generation UUID ?
While you can use any byte sequence you want for a ProximityUUID, they are designed to be universally unique so you can be confident that your byte sequence is not used by others. If this is your goal, you will want to use a dedicated UUID generator, which uses a secure random number generator and a seed value to generate a byte sequence that has a very high probability of being globally unique.
Android has a built in API to do this here: https://developer.android.com/reference/java/util/UUID.html
There are also plenty of online web-based tools that do the same. A quick Google search for "UUID generator" will find several options.
Related
I'm using Airdrop to transfer application internal data between two phones. Because Airdrop was intended for file sharing, it could occur that user choose "save the file" to save the data file in Files app by accident. Since my app is a financial planning app, I'm considering to encrypt the file transferred by Airdrop to keep user's data secure. The encryption only applies to the temp file transferred by Airdrop. Once the app on the receiver phone receivers it, it decrypts the file immediately.
I'm referring to this thread to determine how I should answer the export compliance question if I encrypt the temp file. And I noticed these two exemption items:
(iii) your app uses, accesses, implements or incorporates encryption with key lengths not exceeding 56 bits symmetric, 512 bits asymmetric and/or 112 bit elliptic curve
(iv) your app is a mass market product with key lengths not exceeding 64 bits symmetric, or if no symmetric algorithms, not exceeding 768 bits asymmetric and/or 128 bits elliptic curve.
I don't quite understand the difference between the conditions in the two items (what is a mass market product?). But I don't think either helps, because the ciphers provided by iOS Cryptokit contains only AES and ChaChaPoly - the former takes a minimum key size of 128 bits and the latter takes 256 bits key size.
Since there are a lot of apps using Airdrop to transfer application internal data (I can tell that from the discussions on SO), I wonder how other people deal with this? Is this considered an exemption case?
BTW, I considered other options, but none is satisfying:
Don't encrypt the data. Obscure it instead (for example, using something like Caesar cipher). But that feels very unprofessional.
Don't use Airdrop. Implement my own data transfer mechanism. For example, start a tiny web server on sender side and the receiver side get the data through HTTPS, which from my understanding is an exemption case. I don't choose this approach because a) Airdrop provides a much better user experience than this approach, b) I'll need to use Bonjour to discover service, which requires local network permission. I'd like to avoid that if possible.
The answer depends on what cipher you use to encrypt the data.
Apple summarises your requirements in a couple of documents.
First, in the CryptoKit documentation
Typically, the use of encryption that’s built into the operating system—for example, when your app makes HTTPS connections using URLSession—is exempt from export documentation upload requirements, whereas the use of proprietary encryption is not. To determine whether your use of encryption is considered exempt, see Determine your export compliance requirements.
This leads you to this document which has a table, that I have shown in part:
Assuming that you use AES from Apple's Crypto Kit framework, the second clause would apply. You don't need to provide any documentation to Apple but you should submit a self classification report to the us government.
The exemptions you listed in your question do not apply since you wouldn't use a symmetric cipher with a key length of 64 or 56 bits.
I am reverse engineering a driver that implements HID for the purposes of searching for vulnerabilities.
The main IOCTLs it implements are all from the HID minidriver libraries in the WDK.
I am in particular interested in sending malformed values to the IOCTL_HID_SET_FEATURE IOCTL. However, based on Microsoft's documentation:
https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/hidclass/ni-hidclass-ioctl_hid_set_feature
It is somewhat unclear as to how I would set a feature for one particular HID device as opposed to any other from the documentation. It is a little hand wavy as to what is expected to be in a feature report.
The input buffer size, in bytes, must be large enough to hold the feature report -- excluding its report >ID, if report IDs are used - plus one additional byte that specifies a nonzero report ID or zero.
The Irp->AssociatedIrp.SystemBuffer member points to the input buffer that contains a feature report. If >the collection includes report IDs, the requester must set the first byte of the buffer to a nonzero >report ID; otherwise the requester must set the first byte to zero. The feature report -- excluding its >report ID, if report IDs are used - is located at ((PUCHAR)ReportBuffer + 1).
The documentation refers to the IOCTL as targeting a "top-level collection." but based on my reading of my own driver's disassembly it looks like you can specify features on a granular level, specific to an individual device.
Two interrelated questions here:
Is it possible to target these IOCTLs toward a specific device rather than a class of devices? If so how? If you can point me toward an example of a client that does this, that would be awesome.
What specifically is in a HID feature report/where can I find a spec that defines it?
I'm in the process of writing a CoreBluetooth driver in Swift, and I'm discovering services and characteristics.
One thing that I've noticed, is that the Apple operating system always returns standard Bluetooth characteristics and services as strings instead of raw UUIDs, identifying them.
For example, instead of saying "180A", the log will say "Device Information," or somesuch.
I see these in English. I have no idea if they are localized.
I'd like to be able to access these values for my own purposes (logging and debugging), but I can't find them listed anywhere.
Is there a known, standard place that publishes a glossary that I could use? The best, of course, would be if I could access the Apple pages, but I don't see anything in CoreBluetooth that describes this.
Otherwise, I need to set up my own glossary.
I have 2 devices, and I am looking for a way to sync random number generation between them.
More background: The 2 devices connect, one device sends the other a file containing a data set. The data set is then loaded on both devices. The data is displayed with randomization at various levels. I want the display to be synced between the devices, however still randomized.
A conceptual example: Take a stack of pictures. A copy of the stack is sent to the remote device and stored for future use. The stacks are then shuffled the same way on both devices so that drawing the first picture on each device will result in the same output. This is overly simplified, there are far more random numbers required in my application so optimizations such as sharing the sort order are not applicable...
Breaking it down: I need a simple way to draw from the same random number pool on 2 devices. I do not know how many random draws may occur before the devices sync, but once synced it should be predictable that they will draw the same number of random numbers since they are using the same data sets, however there is a chance one could draw more than the other before proceeding to the next batch (which would require a re-sync of the random data).
I'm looking to avoid having to transfer sort orders, position info etc. for each entity already transferred in the data set at display time (which also raises structural concerns since the project wasn't initially designed to share that info) by being able to generate the same placement, which requires the random numbers come out in the same order.
Any thoughts or suggestions would be much appreciated.
You can use an LCG algorithm and set the same seed for the generation. Because an LCG algorithm is deterministic, as long as you seed both devices with the same seed, they will produce exactly the same pseudo-random numbers.
You can find more information on the LCG algorithm here:
Linear congruential generator
This LCG is used for example by java.util.Random.
If you give rand() the same seed on each device, i.e. srand( SEED );, the (pseudo-)random numbers that come out are guaranteed to be the same every time, and you can keep pulling numbers out indefinitely without reseeding.
Most random number generators let you set the "seed". If you create two random number generators, implementing the exact same generation algorithm, on two different machines (need not even be of the same type or running the same operating system) and then supply both machines with the same "seed" value, they will both produce the exact same random number sequence.
So your "sync" should really only need to transfer one number (generally itself a randomly-chosen number) from the first machine to the second. Then both machines use that same number as the "seed".
(I'd look up the specifics for the iPhone random number generators, but the Apple documentation site has apparently been affected by the Minnesota government shutdown.)
If you do not always want to specify the seed, you could simply designate one device as the master. When the master generates a random number, it sends a message to the other device containing that random number.
If it is truly random no seed number will generate the same number on second machine. It is implied that both random and chaos theories would apply.
I am looking at UUID generation in Blackberrys.
I need to be able to generate 128 bit UUIDs from last generation Blackberrys.
I have just looked through the API and it looks like the javax.bluetooth.UUID class is the way to go.
Can I assume that this API will be available for all Blackberrys? Is there another, more standard/better, way of generating 128 bit UUIDs from a Blackberry?
Edit: I also found this other class net.rim.device.api.synchronization. UIDGenerator. All I need to know is if this is available for all new Blackberries, since I'm not going to develop the app but require a 3rd party developing it to send me a 128 bit UUID.
The Bluetooth UUID class doesn't actually generated UUIDs, it's just a data representation of a UUID for Bluetooth purposes. I don't think there's a native API on the BlackBerry for actually generating UUIDs - you may need a third party library for that.
UUIDs (depending on the definition) are usually just a hash sum of the current time and the hardware (MAC) address (as those are considered being unique) of a/the network device, e.g. bluetooth or WiFi devices. If you don't need to build UUIDs conforming with specific UUID algorithms but just need unique IDs, you could just roll your own easily. Otherwise it shouldn't be too hard to implement a standardized algorithm either.
Look here for some UUID algorithms: http://en.wikipedia.org/wiki/Universally_Unique_Identifier (there are also links to Java libraries for generating UUIDs)