What is the most efficient industry-strength encryption method/library for mobile devices? Ideally, I would like it to be endorsed by the US government for transmitting sensitive data.
I have a number of mass-produced mobile devices, and I want to start encrypting
their satellite and GSM communication. The firmware is in C. My concern is that the battery won't last once I start encrypting.
Many thanks.
Way to platform specific...
Many ARM architectures have native, instruction level support for cryptography.
However, you should understand that you may be able to encrypt the message, but most of the message passing infrastructure is in-the-clear. Second, the standard recommendation for cryptography is NOT to implement it yourself-your implementation WILL be the part that fails first.
In the interest of academic study, I will ask you to consider All the AES You Need on Cortex-M3 and M4 by Peter Schwabe and Ko Stoffelen
As for power concerns, the display and cellular modem are by far the largest factors.
Related
The Altlibary is great at detection! One thing we noticed with testing is if we have an app doing both transmitting and receiving we are not picking up the other phones at times. (Very sporadic) With real devices like ibeacons we are constantly able to pick them up.
My question is how do we control the frequency of the transmitter vs the frequency of the scanning (recieving) so that we can both do transmission and detection at the same time?
My goal is to achieve the best of both worlds scanning and transmitting, is that even possible.
https://altbeacon.github.io/android-beacon-library/beacon-transmitter.html
By default, the Android Beacon Library's BeaconTransmitter uses the highest power and frequency allowed by the underlying APIs in the Android operating system. Here are the settings, showing the defaults:
beaconTransmitter.setAdvertiseTxPowerLevel(
AdvertiseSettings.ADVERTISE_TX_POWER_HIGH);
beaconTransmitter.setAdvertiseMode(
AdvertiseSettings.ADVERTISE_MODE_LOW_LATENCY);
While the settings are configurable, presumably you already want the fastest and strongest advertising for you use case. And that is exactly what the library does with no extra configuration. (Note: there is very little reason to lower the transmit power or frequency, because tests show that transmitters use negligible battery. See my blog post here: http://www.davidgyoungtech.com/2015/11/12/battery-friendly-beacon-transmission)
If you are seeing that hardware beacons are reliable, but some phone models' transmitters are not detected infrequently, then the issue may be hardware issues with those phones themselves. You may wish to characterize which ones are problematic.
I can confirm that I see very strong transmissions from the Pixel 3a, Moto G7, Samsung Galaxy S10 and Huawei P9 Lite I have handy.
I am engineering two BLE devices, a central and peripheral. (Using a PSoC 4 BLE, not that it matters)
There will be a lot of these in a small space, maybe up to 8 within range, but hundreds of peripherals and tens of centrals all coming and going, with no particular rhyme or reason behind which one central/peripheral the user will want to pair at any given time.
I also have an unrelated technology that makes it very easy for the user to move a blob of data from the central to the peripheral of their choosing. I believe this will make pairing much easier in most but not all scenarios.
I figure the non-BLE blob would contain at least the central's mac address, and maybe a randomly generated pin or shared key. Because the blob can only go from the central to the peripheral, the receiving peripheral is really the only device that knows the addresses of the two devices that are supposed to connect.
However, as I understand it, peripherals can't make outgoing connections. I can't swap roles because I still need the BLE search to work the traditional way.
I can think of a lot of ways to get this done, but I'm very interested in hearing the opinion of someone who has worked with BLE long enough to know what might fit best (or if I'm wrong about some assumption).
Some constraints I'm working with:
The peripheral is battery powered.
The usual search and pair method must also still work.
My own half-baked ideas:
Make the peripheral able to be a central too, but then does that
introduce more nuances and complications?
Broadcast from the peripheral, "whoever has X mac address,
please connect to me"
Put a similar message in the advertising packet and increase advertising
rate.
Directed advertising similar to above?
You could let the "non-BLE blob" contain a static random address which the central generates. After the peripheral receives that, it starts advertising with that static random address. The central is also configured to initiate a connection to that particular static random address. Will this work?
Can we broadcast Music using wifi broadcast and listen to thhe same on devices supporting monitor mode.
I would like to listen on monitor mode because I expect the number of devices getting connected is too high for wifi to work properly using IP-protocol.
I want the wifi device to act as a FM broadcast where every device recieves every packets and stream the music.
Are you talking about this Wifibroadcast , here?
If so: well yes, monitor mode is the underlying technology, as can be seen here.
Now, if this is about doing a commercial product, sadly, you cannot expect any kind of interoperability from this.
Streaming audio/video over Wi-Fi is a business, and the the power in charge (Wi-Fi Alliance aka WFA) as some view on it, including certification programs. Have a look at Miracast, using Wi-Fi Direct.
As for multicast / broadcast, it is even more of a business and the realm of proprietary technologies for now (example here - and no, this is not limited to automobile). This is quite complicated, to start with because of the synchronization problem across receivers: you don't want 2 radio receivers in the same room to play with a 1 seconds delay, this would be cacophony.
EDIT:
Meaning, be it with the Wifibroadcast OSS project or with the proprietary industry about it, since there is not yet an open protocol for this (as "publicly available standard specification", I don't even go about implementation, FLOSS or not), you will have to provide a specific application for every receiver to match your broadcaster protocol, and vice versa. And that is the state of the industry today. That is what the company I mentioned above, or this other one more well know, or these are doing. And so, they do not interoperate. This will be your problem: provide a receiver app for Windows, Mac OS, Android and iOS (where you may not even have access to sub-layer 3 API) that will match your radio broadcaster protocol. And Linux too, please.
Though, this is the direction of history because this is what the user wants: stream A/V to/from device/application X from brand A to device/application Y from brand B.
And so people have been working on this, on layer 2, because layer 3 and above have unsolvable challenges with it, at IEEE since 2004 with Ethernet AVB, which is a set of protocols. You can download some of its standards for free, others for a moderate fee depending on how old they are. There is a SIG taking care of certification(http://avnu.org/certified-products/) to guarantee interoperability.
It is for 802.3 (aka wired Ethernet), but there is some work done to bring this to 802.11 Wi-Fi. Because again, that's what the user wants, the market is here, no question about that. It will take a long time. Even more to get consumer electronic grade devices or applications of the shelves. But they will interoperate out of the box, that's the goal.
There's even been work done on moving this to layer 3/IP as well BTW, with some performance sacrifice.
So come back in a few years, and all should be setup. Or, if you have lots of time and money and no urge to deliver, implement a solution based on these standards?
PS:
Link to AVnu (Ethernet AVB SIG) page about use cases for consumer electronics audio streaming, wired or wireless:
http://avnu.org/consumer/
...and its 10 pages white paper at the bottom of the page.
I know both are bluetooth smart devices. I need to know whether both can be used for the same applications. If not what do they have in common and what is different about them?
A sensortag can be configured to be an iBeacon, but it is designed to be a more generic Bluetooth LE device that can be put to many other uses as well, providing many other Bluetooth services.
An iBeacon is a very specific type of Bluetooth LE device, and many types of iBeacons can only perform that one function.
Because a sensortag is so generic, it is not optimized to be an iBeacon. Its battery, for example, will not last a super long time when acting as an iBeacon.
A TI "Sensortag" is basically just an eval board for the CC2540 / CC2541 BLE chips.
Most hardware "iBeacon" implementations use either that chip, or the competing NRF51822, on a more specialized custom board.
In either case, the transmission of "iBeacon"-formatted BLE advertising packets is controlled by the custom firmware loaded into the device.
The duty cycle, which is the major determination of power consumption, is also determined by the firmware. The Sensortag does have some other onboard peripherals, but if the design is sane it should be possible to get those into a negligible powered-down state.
Answering #TimTisdall comment (below), the following link is a 3rd party, non-official iBeacon-enabled firmware update for TI's 2541DK SensorTag hardware:
hex firmware files, demonstrating iBeacon on the cc254x
For more info regarding SensorTag, see:
http://www.ti.com/ww/en/wireless_connectivity/sensortag
&
http://www.ti.com/tool/CC2541DK-SENSOR
This question was a bit ahead of the time and here are some updates: The SensorTag now officially supports iBeacon technology. Information on how to configure it to act as an iBeacon is described in the wiki.
As davidgyoung already pointed out: it wasn't build to solely work as an iBeacon, so it may come with reduced battery life. On the other hand, it provides more functionality, which makes it a valuable tool for development at a good price tag.
As noted before the SensorTag has many other sensors on board. Using a "generic" iBeacon firmware on the SensorTag results in a high current consumption. The unused sensors need to be put into sleep mode (I believe it was the Gyro implementation, which eats a lot of power when not configured correctly in sleep mode).
I want to find a solution to broadcast voice over WiFi for the people in a march. Since Android and IPhone is the most popular devices among the people in the march, it would be great if i can find a solution for audio broadcast over wifi with limited budget.
I know that people in occupy movement use different app on their cell, but it is not suitable in a march in my city. As the authority in my country may temporarily shutdown the data over mobile network to disable the app.
If i can develop an app to gather the broadcast message (SSID) from a powerful wifi AP with a long-length directional antenna, I should able to deliver message among the people in the march. Is it a possible solution?
Also, is it possible to modify the AP to allow any device to join the AP without further acknowledgment and broadcast message to all devices in that network?
Any idea or opinion is welcome.
Many Thanks.
This will be difficult, especially with a large number of users. Since you only need to send audio in one direction, that will at least be a bit easier.
First, you're going to want to put that AP in the middle of the crowd with an omnidirectional antenna. Perhaps, in a backpack or something. Each phone on that network needs to "hear" when other phones are transmitting, or it will be a mess. Even though your application is one-way, 802.11 isn't.
Now, when you write your application, use UDP packets sent to the broadcast address. No need for TCP packets, as they will clog up your network anyway.
Use a simple voice codec, such as AMR. The codecs available vary from platform to platform. See this document for a list on Android: http://developer.android.com/guide/appendix/media-formats.html
Honestly, the easiest solution would be to go buy a small FM transmitter, since many phones have receivers in them anyway.