KeyiCam to use Open webOS for automated key duplication kiosks | webOS Nation

KeyiCam to use Open webOS for automated key duplication kiosks 28

by Derek Kessler Tue, 06 Nov 2012 6:18 pm EST

KeyiCam use Open webOS for automated key duplication kiosks

We already know that Gram's working with LG on an Open webOS-powered television, but as they've been indicating for a while now, they could see the open source successor to webOS getting put to use in a wide variety of applications. While we tend to think of webOS as the interface, there's a lot of behind-the-scenes stuff in Open webOS that's useful to developers. One such developer is KeyiCam (Key-I-Cam), a company that's aiming to make it easier to quickly produce duplicate keys.

KeyiCam's as-of-yet-unlaunched service is a two part system. The first is a mobile app, which we expect will probably produced for leading mobile platforms like Android and iOS (no surprises there). The second is the kiosk. The app lets the user take a picture of their key and send it to the cloud, and to the KeyiCam station where the image is processed to determine the bitting code of the key and machine a duplicate. And if you happen to need a spare or replacement in the future, KeyiCam plans to store your key image so you can create a duplicate in a pinch, so long as you can get to a KeyiCam kiosk. It's not as far-fetched of an idea as you might think.

Where Open webOS comes into this serving as the basis for the kiosk software. The kiosk is being built off of the Devkit8000 board, a compact board of a computer with a 600MHz TI's OMAP3530 Cortex-A8 processor at the core. The Devkit8000 already runs Windows CE, Linux, and Android and has seen its fair share of tinkering from the developer community. Since Open webOS uses the Linux Standard Kernel 3.3, it too can run on the Devkit8000, and run it shall as the basis of the KeyiCam kiosk. Don't expect the standard webOS interface, however - multitasking cards won't have much reason to be in a single-purpose application like KeyiCam's. KeyiCam's told us that the key-cutting application itself will be Qt-based.

KeyiCam plans to deploy thousands of their kiosks across the United States. In addition to the kiosk, KeyiCam's developing a mobile key cutter for locksmiths. The system will work in the same manner as with the stationary kiosks with the customer uploading photos of their keys, but instead of the stationary machine the cutting order is dispatched to an equipped mobile locksmith who, at least as the plan is envisioned, will cut the key and deliver it to the waiting customer. As somebody who's panicked more than a few times about having possibly locked himself out of his house and left his keys - all of them - inside, this part of the service could be a surprising hit, so long as customers are aware it exists. Chances are, though, they won't realize that it's Open webOS that's enabled this kind of magic happen.



Does merging front door key information with a persons name/credit card information like address and full name cause alarm bells to start ringing for anyone else? Replacing passwords online when information leaks is annoying enough, replacing or rekeying a house is a real pain. I'm sure everything (including key shape) will be encrypted on their servers but there are just to many ways of "hacking" accounts (mainly uninformed users) for me to think this would be good for the general public to use.

There is so much potential for abuse that it frightens me.

Security ?

The database that will be holding these key images contains
only the mobile number and password by multiple users associated and no additional information about user for each user account. The last four digits
of the mobile number will be anonymous so in case of a major security
breach theres no use of locating user or users via Google, Bing, or Yahoo!!!. Key Duplication is at Risk due to the High Rampage of SCAMS in America and unarthorized key duplication. Encryption on Servers cannot be discussed here thus we have expert security professionals that developed a method which makes this encryption superb. Also this will create JOB Growth to help reduce the OUTBREAK of SCAMS as this is damaging our economy which the up and coming president should take on this job as its a beast already......



News we hear about the locksmiths scams are true. They are true and are present on a nationwide and remain to keep spreading like roaches. They are deep rooted in every major city in the USA territory. Surprisingly there are a large number of these companies springing up all over the state and they are all connected to each other in forms of unofficial and unauthorized cartels’. Employees of these companies are here on tourist visas. It means that all the employees of these companies on visit visa are illegal and the workers and the company itself can be tailored with legal charges. There have been some in ""Texas"" that were arrested for working as locksmiths without a license and it were found out their visas were out dated and expired and they were deported.

Hmm... weird capitalization, inconsistent use of punctuation marks, all caps, inconsistent. Not very convincing. Your sentence about images and user database is unclear. And you'd better not be storing passwords in databases. Only cryptographically strong salted password hashes are allowed. If you can't satisfy that condition, then there's no trust. Oh, and throwing in stuff about "job growth" just seems stereotypical.

I'd like to know that your expert security professionals are using proven technologies rather than hashing their own. And even then, gotta be careful about it. Remember Microsoft's security experts working on the original Xbox's security? That was a blast.

Passwords are vital, therefore I suggest you to clarify if you are not going to store passwords in clear text. "Only cryptographically strong salted password hashes are allowed". This sentence is true, and everyone of us nerds knows it very well. In that way (hashing and salting), no passwords in clear text are ever stored, and they can't be decrypted in any way from the hash (today). Even MD5 hashes, and hashes without salt, are not secure anymore; nowadays you need the best cryptography. Most customers are incautios and use the same password for many websites. If a cracker gets the password in clear text from one website, he then can very easily access many other websites the victim signed up for, and steal sensitive information. I thank you in advance for any reply you will kindly write to us potential customers of your future application.

I also politely suggest you to pay more attention to communication in the future. Trust is important for an application like yours, and it is gained through good communication. I mean that it seems to me like you are in a hurry when writing comments (punctuation marks, etc.). I noticed it even if English is not my mother tongue.

Seeing this used for a key carving kiosk kinda reminds me of OS/2. Designed to conquer the high tech world, relegated to sucking in PIN numbers and dollar amounts in ATM machines. :(

Sure, there is the problem of encryption, hacking into a database, but what about someone simply snapping a picture of my keys and making a copy of it. How does the company know whether or not it is a lawful copy made. If the key is used in a break in (and presumably not left at the crime scene), how would anyone know the entry came from an unlawful copy made. Am I missing something?

I would generally be as happy as the next guy about more people using webOS but I don't think I like this application.

This is the the answer to "How does the company know whether or not it is a lawful copy made. If the key is used in a break in (and presumably not left at the crime scene)"......

When Mobile Locksmith delivers the key the User will be required to sign signature before releasing the key. Also we will require picture to be taken before making payment via the front facing camera on your mobile device or the back camera.

The Stationary Key Machine will have a camera to take picture of User before proceeding with checkout. Come on thats why we are called KeyiCam we are revolutionizing the way we duplicate keys utilizing the mobility platform and cloud ;).

How are you guys storing the user photos? Temporarily? What about privacy? Also, how good is your face recognition software? If it's the same level as Android's Face Unlock, it's not good enough.

I cannot disclose how photos will be stored here, but you are welcome to join the project as your questions, concerns, and strategies will help strengthen the policy's regarding KeyiCam's security. Also, what I can tell you is that the photo is used as a verification method once photo is sent to server a backup copy is stored on an anonymous server linked to that specific account. The photo on the account is stored temporarily, but the user will be presented with a Policy banner stating that we are not held responsible for usage of this application and that their photo will be recorded. This face recognition is not all complex its basically a special algorithm that scans image to detect if a human face is present if not the application spits back an error until a human face is present.

That last part about the face recognition algorithm doesn't really make any sense. I thought it was to verify the person submitting the key image is the same person that's picking up the new key, not merely verifying a human is ordering a key. Also sounds like it could be easily defeated by any random picture of a human face.

And if the photo is stored temporarily, why does it need to be replicated onto a backup server? And by anonymous server you mean user specified server or some server of unknown origin?

"""" Also sounds like it could be easily defeated by any random picture of a human face.""""
We will utilize smartphones for real eye presence detection that will eliminate these activities. Also, this area I cannot touch on as much so faking the picture will be impossible as the code detects real human eye gaze.

""""detect if a human face is present"""""
So it's face detection (for example Haar-like feature detection) and not "face recognition". Just to understand your comment.

Face Recognition would require a recorded copy to store the facial image, So user would validate against this copy. The face detection is a better option. why ? This wont utilize as much Ram on mobile devices and processing. Basically the code does its scan which detects if this is a real face or not, but the key are the eye's "i" gaze ;).

It's ok to Invent Texting and it's founders are Billionaires easy off Texting and it kills 11 teen deaths EVERY DAY and this Technology is still making billions a year, but it's ok for the Locksmith SCAMS to take place in America ?


Texting While Driving Causes:

1. 1,600,000 accidents per year – National Safety Council
2. 330,000 injuries per year – Harvard Center for Risk Analysis Study
3. 11 teen deaths EVERY DAY – Ins. Institute for Hwy Safety Fatality Facts
4. Nearly 25% of ALL car accidents

Texting While Driving Is:

1. About 6 times more likely to cause an accident than driving intoxicated
2. The same as driving after 4 beers – National Hwy Transportation Safety Admin.
3. The number one driving distraction reported by teen drivers

Texting While Driving:

1. Makes you 23X more likely to crash – National Hwy Transportation Safety Admin.
2. Is the same as driving blind for 5 seconds at a time – VA. Tech Transportation Institute
3. Takes place by 800,000 drivers at any given time across the country
4. Slows your brake reaction speed by 18% – HumanFactors & Ergonomics Society
5. Leads to a 400% increase with eyes off the road

It's a good thing to remind those deaths, even if texting sounds to me a bit off topic here. You won't believe me, but I was just thinking about making a "safe" texting app. :)

This is making less and less sense. What sort of security would detecting faces instead of identifying facial features provide? It can be completely different people picking up the key than ordering it. Signature matching can fail if the same person doesn't do their signature in the exact same style, so that's not great either (though makes more sense than only detecting faces). Saying it takes a lot of resources to recognizing a face than to detect it is a bad reason to lower security. And the RAM/processing requirement doesn't really matter. Today's phones have enough power to do that. There's already Android's Face Unlock, and it works smoothly on modern phones. You've got no excuses.

What's texting have to do with your technology? That is completely off topic. It's starting to sound like some badly written spambot is half answering some question and half throwing random stuff in to make it more popular.

To everyone who is up in arms about how insecure this is - you do realize that the locks on our doors are really just a notification that we don't want anyone to come in, right? I mean, most of us have windows? At least one or all of the doors that we so securely lock with our precious keys are filled with either newspaper or styrofoam. Nobody really needs a key to get into our homes at any time if they really want to. also adds "breaking" to the "entering" if you have to break through a window rather than walk through an unlocked least I think Common Law Burglary requires there to be both breaking and entry.

So, having a locked door/windows, requiring use of a tool (not a key) to forcibly open them/break them, does change simple entry through an unlocked door to burglary. So there is that...but you sure are right...if someone wants in, they can likely get in...and suffer the consequences.

That's why we raise Fer-de-lance and let them roam our house when we are away...and asleep. We've spent the last several years building up a resistance to Fer-de-lance venom...and we also give the snakes names...seems to create a warm, loving relationship between us and them....except for that Cubby, I think he's got it in for us, got to keep an eye on him!

I wonder if I should put a warning sign in the front yard..."These premises guarded by won't have a chance!" or something like that.

I am missing a technical reason to use webOS for this. Why not just use linux with Qt?


We plan on having multiple OS's customer's can select WebOS being we are interested in it's Cloud connected architecture. The WebOS platform deliver's a rich experience utilizing WebKit Qt design, but we do have a KeyiCam Linux Build which we are converting to WebOS that will be submitted to community soon. Also, we are in the works of a KeyiCam Windows version, Android, Meego, and iOS. This will give customer's a wealth of options to choose from we are the first to revolutionize the Key Machine now making Key Duplication Mobility enabled.

My webOS dev knowledge is not great, but shouldn't the main purpose to choose webOS be Enyo? That said, Enyo 2 can be run under any platform with a modern browser. I'm not sure how well the service connection systems work under Qt, but they were mainly designed to be used in a JavaScript environment in the first place. Anything else requires the use of either a helper library or curl directly. Synergy won't cut it, unless you need to sync a lot of flat data to the device.

This idea sets off my warning bells and made the hair on my neck stand up straight...

No thank you.

Security issues aside, why would a kiosk need to dispatch the key data to a locksmith? Why can't it be a full-service kiosk like a Redbox kiosk and issue the key on-the-spot? I can get my pet's name on any color and shape name tag at most pet stores so why wait for a service person? Yes, in mobile situations I can see the need for service, but AAA is faster. (Partnering with AAA would be a great idea.)
This seems much more logical than waiting for a human. I would not think creating a robotic kiosk would be that challenging and and I think it would be far more profitable in the long-run. It could stock the same assortment of popular keys as your local neighborhood hardware store.
Just like Redbox your web/device app would allow a user to locate the nearest kiosk and check availability of the key type as well as dispatch the key to a licensed locksmith when appropriate.

People who are going to abuse this are the same people who already abuse the counter-top hardware store key services.
It's a great idea. WebOS or not.

no offence meant, but all that KeyiCam have posted here, sounds like very strange idea, and even stranger execution. Why on Earth any company would use vaporware OS, as the basis of their EMBEDDED system/hardware??? Why on Earth any customer would prefer to do all this funny things with his keys and smartphone (and expose himself to God knows what unknown electronic risks), instead of just handing the key to a QuickFit point in the supermarket, and have it cut in half a minute, thank you very much, instead of "delivered", God knows when?

...But you seem to thrive on such nonsense, mentioning both webOS AND Meego as one of your target platforms (not sure if only for the client application, or indeed, for the "kiosk" firmware - hard to understand what your intentions are, really, from your writings).

In short, very unconvincing.

Why would these need alot of security. If all is storing is a picture of my key, does it really matter if someone hacks it. What will they get. A picture of a key. Also breaking into houses isnt all that difficult either. I say its a cool idea. All these people who think a criminal having a picture of there house key is the end of the world are naive. Security is an illusion. If someone wants in your house they arent going to hack a key cutting kiosk at home depot.

It's the possibility that they're storing more information than just a picture of a key. They'll need to store your name, signature, and possibly a picture of your face. Do you want an open database with your photo in it? Add to that a mobile number, and you're ripe for your identity getting stolen. Of course security matters,

I'm sorry... but a frontpage history that a potential key-making device will probably use webOS (which for the comments above, is not going to be a big hit among common-sense people)... is trully and relly sad and speaks a lot about the lack of anything interesting about webOS right now...