I am sure that this question has already been answered, but unfortunately I do not know the keywords. Therefore my search remained unsuccessful until now.
Scenario: I want to transmit a lifestream via Mobile Internet using RaspberryPi, and depending on the bandwidth, downscale the streams and upscale them again when available.
My two questions for the network specialists among you:
i know i can actively check the bandwidth, but how would you do this without interfering with the existing processes transmitting? Should I commit a bandwidth to the processes and then slowly determine the remaining bandwidth using a test tool? Or are there already practical solutions?
Can I determine in the mobile Internet, or in the network interface, when a bottelneck is reached?
Passive methods would be my preference. where I wouldn't have to load the bandwidth. e.g. I could know how much bandwidth the stream uses, and how much arrives. But how do I make sure there is enough capacity before I go up with the bitrate?
Thanks for your wisdom ;)
It's well known that botting is one of the most great thread for MMORPG games. Since it's releatively easy to detect clint injection, I wonder how can MMORPG detect botting from server side. Thanks for any help.
By reading some papers, I figure this question by myself.
Here are two kind of major bot detection methods: detected by Sufficient Condition and detected by Necessary Condition.
For Sufficient Condition, it's always useful to detect behavioral action or social action.
For Necessary Condition, it's usually useful to detect Transaction Network Analysis.
My goal is to implement a routing algorithm for attack detection using packet delivery ration calculation on a Zigbee module(hardware). I would like to know if it is possible to implement this on popular zigbee modules like NXP, TI, SiLabs. I tried Digi Xbees already but can't find a way to modify the route discovery process. Any suggestions and ideas are welcomed.
Thanks.
Daniel Emehinola
Zigbee is a standard that defines several layers and the implementation of these layers is usually provided by the chip vendors, which in order to ensure people do not mess with these implementations, they provide many of these layers in the form of libraries so customers of these chips only have to care about implementing the application or modify existing sample apps, being said that, you need to find a Zigbee implementation that is open source, otherwise you wont be able to change the behavior or the routing mechanisms.
Hope this helps!
So we are a startup been doing most of the work on cloud and looking at moving processing on device itself, so owner of the devices don't loose functionality once we decide to move on.
But we had this question we are debating is
Do IOT devices provide real privacy of data?
I know "real" is very subjective, but if we decide otherwise. Please suggest
Any supportive studies either ways. Seems like a broad question .. but
I think a lot of it would depend on what data are you retrieving from these devices and how are you handling it in cloud.
Also i think it would depend on the hardware of the device; like how much secure it is from that point of view
This is way too broad. A large proportion of IoT devices are horribly insecure and also offer little in the way of privacy. So if you're talking about existing devices, then the answer to your question is no.
That doesn't mean that IoT is inherently insecure or privacy-invading, just that the vast majority of devices have chosen to make it so, undermining trust in all of it - look at all the stuff that Google and Amazon have been trying to get away with.
You can of course build your own, but when you say "once we decide to move on", it suggests that you want these devices to operate peer-to-peer without a cloud connection (i.e. when there's nobody paying for servers). This is entirely possible using things like tor and signal protocols, but it's not easy, and you're unlikely to find a comprehensive answer on Stack Overflow. You're going to need some good privacy- and security-aware developers to make that work, and they won't be cheap.
I've been involved in a discussion about how to build internet voting software for a general election. We've reached a general consensus that there exist plenty of secure methods for two way authentication and communication.
However, someone came along and pointed out that in a general election some of the machines being used are almost certainly going to be compromised. To quote:
Let me be an evil electoral fraudster.
I want to sample peoples votes as they
vote and hope I get something
scandalous. I hire a bot-net from some
really shady dudes who control 1000
compromised machines in the UK just
for election day.
I capture the voting habits of 1000
voters on election day. I notice 5 of
them have voted BNP. I look these
users up and check out their machines,
I look through their documents on
their machine and find out their names
and addresses. I find out one of them
is the wife of a tory MP. I leak 'wife
of tory mp is a fascist!' to some
blogger I know. It hits the internet
and goes viral, swings an election.
That's a serious problem!
So, what are the best techniques for running software where user interactions with the software must be kept secret, on a machine which is possibly compromised?
It can't be done. Fortunately, banks face exactly the same problem, so those little home chip'n'pin doohickies are pretty cheap.
So, if you want secure online voting, you send a custom voting doohicky to everyone who applies for one. This doohicky signs and encrypts their vote before sending it to the PC to be transmitted over the wire. The only thing an attacker on the wire can do, is eavesdrop whether or not the voter voted at all. Since political parties already do this, by posting party workers outside polling stations, that's not a significant risk to the system ;-)
You still face some of the problems of postal voting, such as vote buying and coercion, or stealing someone's doohicky, but only via physical access, not by compromising their PC. There's obvious DOS attacks if you rely on home internet connections, but there's no reason the voter can't have the option of going to the polling station if their connection goes down.
Whether the doohicky is cheap enough is still doubtful - I guess they cost a few pounds each, which I don't think is cheap on the scale of what is actually spent on elections. But they're not infeasibly expensive. I doubt they save much money at polling stations, unfortunately. The cost of polling in the UK depends pretty much on the number of polling stations. Problems this time notwithstanding, the number of polling stations isn't driven by the need to provide a fast enough throughput, it's driven by a desire that people not have to travel far to get to them. So having fewer voters doesn't really allow you to reduce the number of polling stations. Reducing paper might save time and money at the count, but surely not enough to pay for doohickies.
Finally of course there's still a risk of attack on the hardware. Someone could maybe intercept them in the post and replace them with identical-looking devices. But unlike attacking the hardware at a polling station, the attacker only affects one vote per piece of dedicated voting hardware compromised, so at least the bar is set high to begin with.
So, what are the best techniques for running software where user interactions with the software must be kept secret, on a machine which is possibly compromised?
The only answer is that you cannot / must not do it. If the hardware or OS might have been compromised you cannot guarantee to keep the user interactions secret.
But the other take on this is that no voting system known to mankind (electronic or otherwise) is incorruptible. That is why you need to have people checking for fraud, and people watching the people, and a culture where corrupt behavior is not the norm.
EDIT
... if one can reduce the impact of compromised machines to below the level of corruption in a paper voting system you're achieving a positive gain.
You also have to take into account other forms of corruption that are much easier with electronic voting from home. Like stand-over tactics, votes for sale, the fact that most people do not properly protect their electronic credentials, etc). In short, what you are proposing is hypothetical, and (IMO) unrealistic.
It is simpler to fix the flaws with in-person, on-paper voting than to address a whole bunch of potentially worse problems with a hypothetical from-home, electronic voting.
(Also, you are implying a level of corruption with UK paper voting that surprises me as an ex UK resident. This is off topic, but can you provide references / links that back this up?)
You have two main choices, either sidestep the comprimized part of the machine (e.g. provide the full OS) or work within the comprimise and make it hard to get hold of the data.
The second choice is more practical. Although you can't stop the shady dudes from eventually getting the data, you can make it difficult enough that it will take longer than a day, rendring the leaked voting habits harmless.
Assuming a web application, not using standard UI components and varying their locations on the screen, using multiple layers of encryption, disabling keyboard input, and using animations to fool screen grabbers can all make the process tricker to buy more time.
Obviously you can not ensure confidentiality of the vote if the machine the vote is entered with is compromised. Whatever measures you take, all an attacker needs to do is to execute your software in a virtual machine that records all access to keyboard, mouse and screen. By playing back the recording, the attacker can see how the user voted ...
However, when designing a E-Voting protocol this is the least of your worries. How do you prevent somebody from hacking the election server and manipulating results? How do you even detect tampering? What about the secrecy of my vote if the server is compromised? Can I be forced to reveal my vote?
The biggest threat facing e-voting is the ability for an attacker to influence the election. By spending CD's to people you make Massive Identity Leaks more valuable. Not only can an attacker destroy their credit, but they can also destroy their country.
Even forcing people to use specific hardware doesn't work. Look at console modding, or ATM Skimmers and Hardware Keyloggers. You have to worry about transferring the votes to be counted, even SSL has secuirty problems. There are also the problem of the centralized database, sql injection would be devastating.
The real question is, "Is e-voting more secure than paper voting?" What is harder for an attacker to influence? To be honest I don't think e-voting machines would have changed the outcome of the recent Iranian election.
An obvious solution is to send the software to the end user on a bootable CD. The user simply restarts their computer and they're now on a non compromised computer.
However, this is not terribly simple to develop (trying to make the OS on the CD compatible with all the variations of hardware we're going to encounter on machines). Also, I can't imagine that the average home user has their BIOS set to "Boot from CD" and telling voters to modify their BIOS settings is just going to far.