3. What is KIWI.KI?
• Hardware Startup based in Berlin
• Completely hands-free entrance to the
Front Door of Multifamily Buildings
• Doors are always connected to our
infrastructure
• Access can be granted or revoked instantly
from anywhere with an internet connection
4. Why the Front Door?
• Typical apartment building has at least 12
families…
• … and mail delivery
• … and package delivery
• … and trash removal
• … and contractors
• … and is already electrified!
5. System Design Goals
• Scalable, centrally managed,
physical-access-as-a-service platform
• No reliance on outside connectivity
• Privacy, Security tied with User Experience
6. A note about Privacy
• Investors and Sales hate this aspect, but
have to live with it.
• We are not another big-data startup
• Our system is designed to know as little as
possible:
– Our doors don’t know whom is using them
– Our doors don’t report real-time usage statistics
– Our Ki don’t transmit unless first awoken
– Our Ki don’t transmit unique/identifiable info
7. A note about Security
• Security comes in layers, the more layers the
better security
• Security is based on
open standards—and
open scrutiny
• Security is proactive
• Security is like Pandora’s box
8. A bit about Hardware
• We design and manufacture all of our own
hardware (in Berlin!)
• The hardware is an extension of our
software platform
• The hardware enables us to provide our
services to our customer
• The hardware is a means, not an end!
• We helped to found hardware.co
10. KIWI Infrastructure: Sensors
• May be powered, may not be powered
• Sensors
– digital and analog inputs
– digital and analog outputs
– some amount of configuration
– crypto secrets
• Communicate through Gateway Nodes
• Doors are just another ‘sensor’ type
– Valid Ki, Invalid Ki, etc. are ‘Inputs’
– Cache credentials, decision is taken locally
11. KIWI Infrastructure: Backend
• KISS: Less is more
– Many small dæmons doing one thing well
• Coordinated over AMQP
• Distributed between several datacenters in
Germany
• Keep as little state as possible
12. KIWI Infrastructure: API
• All interaction with the system from end
users comes through the API
– Residential customers managing access or
opening doors remotely
– Electricians installing KIWI sensors
– Manufacturing rigs asking for secrets for new
devices
13. KIWI Infrastructure: Apps
• Residential Application for managing
household account
– Invite people to your door
– Open door remotely
– Activate new Ki
– Change Billing
• Electrician Application
• Operations Application
• Hausverwaltungen Application
14. Opening a door via API
1. Client has existing session id with
permission to the door
2. Client sends API request to open door
3. API sends AMQP message
4. Crypto Services creates encrypted message
5. Socket Server sends message to Gateway
6. Gateway sends message to Sensor, which
opens (~200mS from step 1)
15. Realizing the system
• More than 350 houses equipped with KIWI
• More than 225 gateways installed across
Berlin
• More than 1000 Ki with Customers
• Deutsche Post and ALBA in large-scale trial
16. Some interesting statistics…
• Number of log messages indexed per day
>6M
• Number of door openings in a month
>90K
• 37 Repositories in Gitlab
• SLOC (missing: javascript and sql)
– 30k lines of ANSI C (firmware for doors, Ki)
– 10k lines of Python (infrastructure)
17. The Future!
• Entrance doors just the beginning
– Private doors
– Commercial doors
– Package delivery
• Managed access to doors -> managed
access to sensors -> managed access to
information
• Sensor network available to third parties?
18. Who is KIWI.KI?
• Three founders covering Operations,
Finance, Sales, Marketing, HR and Legal.
• Headcount: 25 (Seven developers)
• Based in Berlin
• From all over the world (Spain, New
Zealand, Japan, Poland, United States)
We’re hiring!
19. Summary
• KIWI.KI is manifesting the internet of things,
today
• We’re building our own…
– Hardware
– Infrastructure
– API
– Applications